Added static builders and abstracted reflection components

[EdwardCooke]

When doing an AoT/trimmed library, nstead of using SerializerBuilder and DeserializeBuilder use the StaticSerializerBuilder and StaticDeserializerBuilder. There should be a couple of warnings that will show up when using the current SerializerBuilder and DeserializerBuilder and AoT/trimming. The static ones don't use reflection anywhere, thus, no warnings. There was a bunch of areas in YamlDotNet that was generating generic classes when a custom dictionary object didn't implement IDictionary or a custom list didn't implement IList. That's probably the biggest limitation in the static version, and I couldn't find a way around it.

My testing showed that the static builders worked for the simple serialization without showing any warnings. I'll be working on setting up unit tests for the static implementation over the next bit. If you don't find any issues, I'll bring those changes in to the master branch when the unit tests are complete and push a new version.

There are some minor breaking changes in some of the underlying interfaces/classes, namely the IObjectFactory, there is a new class, ObjectFactoryBase that can be inherited from, which will cover the current implementation without needing to write any additional code or other changes. If you manually instantiated some of the node deserializers, there will need to be code changes, they now take in a ITypeFactory and/or IObjectFactory object.

Those changes were necessary to break out the rest of the reflection implementation so it could be replaced with the static implementation.

Resolves warnings in #740 and #753

[EdwardCooke]

@aaubry this PR will be pushing up a second NuGet package for the static code generator/analyzer. Do you have any issues with this? The NuGet package name is YamlDotNet.Analyzers.StaticGenerator.