14438 database representation of scripts

[arthanson]

Fixes: #14438

Adds database representation of scripts. There are several parts of this:

• Adds the actual Script model
• Update all jobs that point to the module.script to point to the new Script object and update associated code
• Update all event rules that point to the module.script to point to the new Script object and update associated code

The action_parameter on EventRule is removed as it was only used to save the name of the script as the action_object pointed to the script module. It now points directly to the Script model. If the script named in the action_parameter no longer exists then a dummy Script object is created with is_valid=False.

API

The API was kept as compatible as possible, mostly adding in the new is_valid flag. As the old API was driven off of the module, it would only return scripts that were actually in the module. Now if a script is deleted in the code behind the covers we just mark the script as is_valid=False and it is up to the user to actually delete it, so now the API can return these 'ghost' objects.

The API also still allows referencing by the string 'module.script_name' for backwards compatibility, where the new one just uses id for the script object.

Also, as backwards compatibility was preferred - there are some updates that could be done to the API that would be more breaking changes to keep it more in-line with other APIs, but were not done. For example - the jobs could be returned on the Script object but wasn't as that would be breaking and it could introduce a lot of bloat to the returned data if there were a lot of previously run jobs for a script.

*Note: I had to make two migrations - if the remove event_rule.actions_parameters was done in the first migration it would error with "django.db.utils.OperationalError: cannot ALTER TABLE "extras_eventrule" because it has pending trigger events"

[renatoalmeidaoliveira]

Maybe adding TagsMixin, ChangeLoggingMixin and JournalingMixin may give user some flexibility and better experience in the usage of Scripts models,
The TagsMixin may allow users to create granular constrais to Scripts Models allowing/restricting user from run/edit some Script
The ChangeLoggingMixin might be usefull when running the datasource sync because it may create changelogs when the script changes in the data source giving the user a better understanding of what is running
The JournalingMixin may allow users to track development or comunnicate with each other within the Script Model