Refactor IUnknownValueFactory to IValueFactory and use it throughout the entire library

[Washi1337]

Summary:
Current implementation of the CilVirtualMachine heavily relies on the user creating and using the appropriate IConcreteValue derived type, with all the right parameters.

This has a couple of downsides:

• It is not very intuitive. When do we use concrete value? When CLI value? When do we allocate our own instances, and when the IMemoryAllocator?
• Because of its complexity, it is also very error prone.
• It is not very flexible and scalable. If the API changes (which it still does regularly), all references need to be updated.

We already have a factory interface for constructing unknown values by type, but this could be extended to known default values as well (e.g. zero values).

Advantages:

• Centralized place for constructing instances of IConcreteValue from a ITypeDescriptor, without the need to actually construct the objects yourself, and therefore the knowledge of which types to use for which use-case.`
• No confusion about which of the factories to use if there's only one factory to be always used.
• More flexible and future proof. If some implementations of certain value types changes, this only has to be changed in the implementation of the factory, rather than all over the project.
• The factory can also help in being more expressive about the intention of the created values.

Places that could highly benefit from this change:

• VariablesState currently initializes its own UnknownValue instances for default variable values. This can be improved because variables have a type assigned to them, so we actually know more information than a completely unknown object.
• The same holds for fields in an HleObjectValue instance.

Side note:
There might be a need for a MakeAllUnknown method for easy resetting of the variables state.