Split the execution and edition rights on models

We want to allow anyone to register in demo and run processes on any public models so we can look cool attract customers to our wonderful platform. While the docs did say that a user can view any available model version with a tag set as long as they are marked as guest, and our ACLs always make public imply a guest access, [Partial]UpdateWorkerRun still requires a contributor access to execute the model.

Changing the existing ACL checks to allow guests to run those available model versions would also make them able to create new model versions out of nowhere, or edit existing available model versions and remove the tag to shoot themselves in the foot, because our current ACL mixins are split by role (guest/contributor/admin) rather than by action (permission to view/execute/edit/delete/…).

On top of those issues, multiple mixins cannot be used at once since they can override each other's behavior, so an API that checks for ACLs on both models and workers could show unexpected behavior. We also have regularly had to use weird hacks to make those mixins work with serializers, since they were only designed to work with API views, making it harder to follow the best practices.

We can make our permissions more flexible, make implementations require less hacks and be less prone to errors or inconsistencies by moving all permissions to two different places and defining methods related to actions, such as executing or editing a model, instead of related to roles. For example, to list all models with execution access, we could use Model.objects.executable(user). Once you have retrieved a Model, if you want to check for its rights, you could use my_model.is_executable(user). This can more easily be tested independently of any API endpoints, so any future updates to the rules on how a model can be executed by a user are easier and safer.

We should consider migrating all of our ACL checks to such a system to avoid having duplicate ACL checks in place, but specifically in the context of https://redmine.teklia.com/issues/4863, we can probably get away with just Model.is_executable and Model.is_editable, or their QuerySet counterparts.