Stable error codes in operation validation

[goto-bus-stop]

This issue is similar to, but more limited than #824.

Today, validation errors are returned in a format that's intended to be user-friendly (whether for CLI or JSON output). But it's not very friendly to programmed consumers. Today, clients that want to inspect the validation result need to match against error messages.

We want to evolve error messages over time and not maintain them as public API. So we should explore putting validation error data in extensions instead.

I think the primary use case here is to have error codes for spec validation rules for executable documents. Schema validation is not likely to affect non-human consumers (if a schema fails to validate you simply can't use it, and it's most likely a developer or a platform team that sees the error). Meanwhile operation validation errors may be used in application tests or even to show different messages to end users. Limiting error codes to just that also makes things easier: we don't have to invent new codes, we can reuse the names of the rules from the spec for the most part.

I would not expose any other data about errors for now. Maybe there is a use in the future for reporting the names of types or fields involved in an error in a structured format, but let's not do too much if there isn't a clear use case for it.

Maybe the key in our .to_json() implementation could be "validationRule":

{
  "extensions": {
    "validationRule": "LeafFieldSelections"
  }
}

If users want something else they would use err.code() -> Option<ValidationRule>.