Make tasks more like deployments

[shreddedbacon]

Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for changelog and subsystem label(s) applied

When looking at #3106 I noticed that there are some differences in how tasks are created, updated, and displayed in the API, versus the same for deployments. Really though, they should be the same or more similar, they both use similar delivery mechanisms from core->remote.

One of the main things is that in tasks we use active, succeeded, and failed as the status types. But in deployments we use new, pending, running, completed, failed, cancelled, and error(but this isn't used afaict).
Tasks should also have these same states, where when creating a task it sits in a new status until the controller processes it and it goes through to pending, then running, and eventually completing or failing. Adding these new enums into the API is a first step to supporting cancelling tasks.

Currently the remote-controller (v0.3.0) will send only the statuses that the API is expecting (active and succeeded/failed), introducing the additional enums won't break anything as the existing enums remain in the API for now. Eventually the controller will be updated to send the newer enums that the API knows about. This allows this PR to be backwards compatible with older controllers, and once controller support is added, core will know how to support them out of the box.

Another of the features is adding a new taskName field to tasks. This is an autogenerated name that is generated similar to how builds are generated, being lagoon-task-xxxxxx. New queries and mutations (WIP) will be available to interact with tasks using this taskName. To account for this new field, a migration function is added to api-db that will go through and generate a taskName for any tasks that are missing this field when rerun-initdb is called. This allows the UI to start using this new taskName field as a router query/slug instead of using the tasks ID number.

As this is intended to be backwards compatible support for the new features, there will be follow up issues raised that will need to be tackled under debtsmash labels to remove identified functionality or deprecate things later on.

Closing issues

Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if such).