[FEATURE] Container variant type improvements

[stevejgordon]

Container variant types are code generated as a class that encapsulates the variant name and the variant object, with factory methods for creating each built-in variant type. This makes them reasonably easy to work with when using them in requests but challenging to use when accessing them in responses.

The code-generated class includes internal properties for the Variant and VariantName but doesn't expose ways to access the variant. Currently, in v8.0, we manually add a TryGet<T> method to these types. We do not "mark" variants which limits our ability to constrain the generic T on the TryGet method.

We should enhance the code-generation to make these types easier to use:

Enhancements

Beta Give feedback

1. Create a marker interface for variants
2. Identify common base properties for all variants. Check if they all share a common ancestor with the name in the form VariantNameBase. If so, these are assumed to be common properties we should include on the interface.
3. Expose the variant name publicly.
4. Generate TryGetVariantName methods for each variant.
5. Generate bool ContainsVariantName methods for each variant.
6. Generate a general TryGet method for non_exhaustive containers.
7. Consider generating conversion operators for each variant. This might be a step too far.
8. Where the container includes container properties, we should include overloads of the factory methods that accept these as (optional) arguments. This simplifies the usage, for example, when adding weight to a function in the FunctionScore. Alternatively, consider adding WithXyz methods for container properties which allow chaining from the factory methods.

An example of where this applies is the Processor container type.