Refactor GroupDeployKeys model and Introduce FF

Context

In order to start/continue work on GroupDeployKeys UI and API (#232835 & #232837), we need to ensure that the GroupDeployKey model is treated similarly to the DeployKey.

Among other things, the GroupDeployKey should have the same validation checks as the DeployKey, as well as audit events and expiration notification.

In a previous issue, GroupDeployKeys were introduced with a model that is separate from DeployKeys. (See #14729 (closed) and related MRs). This makes aligning the GroupDeployKey with the DeployKey difficult (see problems mentioned in #330323 (closed) and !60809 (closed)).

We want to merge the model of the GroupDeployKey to the DeployKey so that their functionalities/capabilities are better aligned without needing to do a lot of additional work.

Proposal

1. Re-structure the model of GroupDeployKeys

The DeployKey is just a type of Key, and persisted in the keys table. The DeployKey is then associated to a project through the deploy_keys_projects association table. Group-level deploy key should follow the same pattern that DeployKey is associated to a group through a deploy_keys_groups (DeployKeysGroup) association table.

Essentially, the work done in #14729 (closed) will be refactored to follow the above model.

This means we will drop the group_deploy_keys, group_deploy_keys_groups tables (and corresponding models) effectively. The GroupDeployKey feature is unfinished, and it is not exposed to any end user, so dropping the tables and classes should be safe to do so.

See discussion: #330323 (comment 1369676048)

2. Introduce a Feature Flag

A Feature Flag should be introduced for the GroupDeployKey so we can hide any incomplete functionalities from the user before the access checks, UI, and API are implemented.

Some changes already introduced in #14729 (closed) may need to be put behind the Feature Flag.

See discussion: &10409 (comment 1369886056)