Add an extension point for deployment-specific metadata properties on projects, repositories and tokens

[ikhoon]

Motivation

Organizations running Central Dogma often need to attach deployment-specific properties to Central Dogma resources.
For example, a deployment may require every project to carry the identifier of its owning service in an internal
service catalog for ownership tracking and access control. The same applies to repositories and application
tokens (app identities).

Central Dogma currently provides no way to declare, validate, store or retrieve such properties:

• ProjectMetadata, RepositoryMetadata and AppIdentity have no extensible attributes field.
• The creation APIs (POST /api/v1/projects, POST /api/v1/projects/{projectName}/repos,
  POST /api/v1/appIdentities) accept only the predefined fields.

As a result, a deployment that needs such properties has to fork the metadata model and the API layer.

Proposal

Let an administrator declare the additional properties in dogma.json, grouped by resource type — each resource
type is the parent of its own declaration, and the declaration itself is a standard JSON Schema instead of a
bespoke format. A rough sketch:

{
  "metadataProperties": {
    "project": {
      "type": "object",
      "properties": {
        "serviceId": { "type": "string", "pattern": "^[a-z][a-z0-9-]*$" }
      },
      "required": [ "serviceId" ]
    },
    "repo": { ... },
    "appIdentity": { ... }
  }
}

• The values are provided by the caller: the creation APIs for projects, repositories and app identities accept
  an optional properties object.
• The server validates the declared properties with an existing JSON Schema validator library and rejects a
  non-conforming request. Undeclared properties are ignored — not rejected — so a new property can be declared
  with a rolling restart without failing requests on replicas still running the old configuration.
• The web UI renders a form from the declared schema in the corresponding creation dialogs, and the schemas
  are exposed through an API so that other clients can do the same.
• Validated properties are persisted with the existing metadata — e.g. a properties field on ProjectMetadata,
  RepositoryMetadata and AppIdentity — and returned by the retrieval APIs.
• Validation that a schema cannot express (e.g. checking a value against an external catalog) could be delegated
  to a ServiceLoader-based SPI, similar to the existing MirrorFileValidator.
• When nothing is declared — the default — nothing changes for existing deployments.

Out of scope

How a deployment makes use of the stored properties (e.g. grouping or filtering resources by a property value)
is out of scope. This issue only proposes the generic mechanism to declare, validate, store and retrieve them.