[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
- [ ] Create a marker interface for variants
- [ ] 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.
- [ ] Expose the variant name publicly.
- [ ] Generate TryGetVariantName methods for each variant.
- [ ] Generate `bool ContainsVariantName` methods for each variant.
- [ ] Generate a general TryGet<T> method for `non_exhaustive` containers.
- [ ] Consider generating conversion operators for each variant. This might be a step too far.
- [ ] 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.