Validate mutually exclusive traits

What

Investigate adding an optional property to the YAML schema for traits, for calling out other traits that are mutually exclusive to this one, and so should not appear in the same trait set.

If possible, validate at generation time that specifications do not violate this condition, and validate that mutually exclusive lists are consistent with one-another.

Why

The absence of a trait from a trait set does not mean the negation of that trait. In order to represent negation, we need a separate trait to represent the alternative.

Such opposite pairs of traits should clearly not be allowed together in the same trait set.

It is also not always clear at a glance what the "negative trait" for a given trait is.

More generally, there may be arbitrarily large subsets of traits, elements of which should never appear together in the same entity trait set (or specification).

So from both a validation and a documentation perspective, having a structured way to describe mutually exclusive groups of traits is valuable.

Notes

Cross-package mutually-exclusive traits present a difficulty for validation. So we can either skip validating these, or revisit the idea of requiring the .yml of dependencies during generation.

Start by tracing the YAML trait schema and the generation-time validation entry point. Define how an optional mutually exclusive property and list consistency checks should handle same-package and cross-package traits. Done means invalid trait sets and inconsistent declarations are rejected, with the supported behavior documented.