Support custom templates

[MelGrubb]

Make use of an assembly-level attribute to override higher-level items like the base class template, or to override templates on a global basis.

Consider allowing attribute parameters to override individual templates so that you could have multiple, alternative versions of certain templates, some of which get used for some classes, and some of which get used for others. I'm not sure this is as immediately useful, though. Interesting, but probably not worthwhile.

[MelGrubb]

There's a conceptual problem preventing this from moving forward. The only place to specify the version of the templates you want to use would be in the attribute. What if you tagged up different classes with different template versions? Who would win? On the surface, it seems like this would be great, you could use different templates for different classes if you wanted to, but what about the shared classes like the base class or the attribute itself? Those can only be specified once, and they will dictate the version of everything else.

For instance. C#11 allows the use of generic attributes, so we could have [BuilderFor<Foo>] instead of BuilderFor(typeof(Foo))], but that makes it incompatible with projects using previous C# versions. It might be possible to specify the template version with an assembly-level attribute. If no template is specified, then it could default to the latest version.

I'm exploring that now.

[MelGrubb]

Notes for future me:
The templates have been moved into embedded resources which are loaded by the generator's static constructor. A base "Template" class with matching properties can be extracted as a first step. That class' static constructor could load the templates from their resources and expose them as properties. The attribute could take a type reference and possibly instantiate one of those.

I think a better solution might be adding templates to the target project and marking them as additional analyzer files instead. The initializer for the generator can look for these additional files and overwrite the template properties on the Generator class if they are found. In that case, there is no need for an attribute or to separate out the templates into a separate class, although that might still be a good idea for organizational purposes.