Allow importing and exporting Policy definitions

### Current Behavior

Currently, there is no way to import and export defined policies, and the operator must rely on the database to store these definitions, and create backups when upgrading the platform, to avoid any potential data corruption during the upgrade.

Additionally, there is no way to know that the alert configurations haven't been changed since they were created, as no such events are recorded at the system level, making tracking such changes virtually impossible.

### Proposed Behavior

It would be great to have the ability to import and export policies, in common document formats, such as JSON, YAML and TOML, for example, to reuse when instantiating a new deployment of the platform. This would also allow managing them with any version control system, and modifying and reviewing them by humans.

The immediate pitfall I see is the fact that policy descriptions are decoupled (not a bad thing), relying on UUIDs of the various parts to describe a policy.

Disregarding the potential for colliding identifiers, when reused on another system, exporting the objects with their UUIDs would not be ideal, as this is an internal identifier, used by the platform, and not relevant to the end-user. This is made more-so unnecessary considering that the identifiers are generated upon object creation, and this would be a deviation from that flow elsewhere in the platform.

On the other hand, some unique identifier would allow the user to verify that these the policy definition objects on the platform are the same ones as seen in their external form, but hashes would be a much better option for this case.

This would thus require resolving all of the policy database objects to create a literal description of the entire policy. The problem with this approach would be a collision between the literals (such as policy names, referenced object names, and so on). This would require some ability to specify a resolution strategy, and when/how to apply it. This seems more natural, but also increases the complexity of this whole effort.

Questions I'm currently mulling over are "If I'm importing a large list of policies, and one or more of them already exists on the system (by name? by rule parity?), how should this be resolved? Should the platform reject the whole import? Should it reject only the ones that collide? What if my user simply updated a policy and wants to replace the old version of it? How would they specify the resolution strategy - before the import or during it, as errors occur? What if the user wants to resolve different conflicts differently? How would this complicate the frontend?"

_I apologize if this turned out into a bit of rambling, but I wanted to write this out so it's out of my head and maybe serves as a starting point for some sort of discussion._

### Checklist

- [X] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [X] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested