User Defined Spectral Rules

## Feature Proposal

Support an additional section in architecture and patterns which allow the user to define a set of Spectral rules which would be ran during validation.

This would allow pattern owners to capture additional semantic checks in addition to the structural rules they get from JSON Schema, and the default semantic checks that are built in to the validate command. E.g. a patten author might want to enforce certain naming conventions in nodes:

> [!NOTE]
> This is just a quick example, and not necessarily how we'd want to represent these in a final design

```json
"rules": {
"service-naming": {
"description": "Services must follow naming convention",
"severity": "error",
"given": "$.nodes[?(@.node-type == 'service')]",
"then": {
"field": "name",
"function": "pattern",
"functionOptions": {
"match": "^[a-z]+-service$"
}
}
}
}
```

Or in Pattern options, this could be useful to enforce more nuanced aspects of the architecture that only apply when a choice is made. Here's one example (not the best example in the world but shows the point):

The pattern author wants to restrict architectures to be deployed to one of two regions, A or B. Region B is deemed to be a more risky area and therefore should have higher resiliency in the architecture. To enforce this, the pattern author includes a rule which checks that the number of replicas for a given node is a high number.

> [!WARNING]
> this is not at all valid CALM, but rather just to illustrate the point logically
```json
"pattern-options": [
{
"question": "which region are your services deployed in?",
"choices": [
{
"name": "region A",
"rules": ["greater-than-2-replicas"]
},
{
"name": "region B",
"rules": ["greater-than-4-replicas"]
}
]
}
]
```

I can expand on the above example to make it more concrete if it's not clear what this would look like in ac actual pattern and instantiated architecture.