refactor: store PEDM configuration in SQLite instead of JSON files

[Richard Markiewicz (thenextman)]

Previously the PEDM profiles and assignments were wrapped up in a Policy object, which was loaded at startup and then maintained via an IdList structure. API calls would have the Policy in their context and interact with it directly.

This PR:

• Strips out unused features from the API surface area (session / temporary elevations, revoke elevation). We don't support them right now and it just adds noise.
• The remaining Policy item needed for elevation is the current user selected profile. We load this from the DB at the API front -end and pass it back to where it's needed.
• The API now calls the database directly to query/update/delete. In most cases transactions are used where we need to enforce consistency, but we are not expecting a high volume of calls or needing a high level of atomicity.

The API and database design is not the most well thought-out, but it closely reflects the existing APIs to minimize disruption elsewhere (API clients like RDM, as well as avoid significant behaviour changes that may introduce new bugs).

Concerns are:

• There's no effort to maintain compatibility here. Existing PEDM users will need to uninstall, wipe out their %programdata%\Agent\pedm directory, and reinstall. Internally I'll provide a script to do that. RDM will be blocked from using any version that doesn't include these changes.
• The handling of users is not optimal (see Allan Zhang (@allan2) related PR). This goes back to Kyle's original implementation and if we had made these changes earlier, we could've addressed it, but there is no time now. We'll have some technical debt here to correct in the future.

[github-actions]

Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

[Benoît Cortier (CBenoit)]

LGTM! I don’t see any blocking issue 🫡