Resolve "Change to use Entry Assembly to identify application causes issue for some CLR versions or for when our (managed) code is called from unmanaged code"

Closes #29 (closed)

The issue here is that for some use cases (most commonly a managed .net assembly being loaded into the process of an unmanaged executable - a possible use case and something that is happening when running the unit tests on Windows for .NET Framework 4.7.1) the Assembly.GetEntryAssembly() static method will return null.

This causes a problem for the UserAgentBuilder class which is attempting to default to setting the application name and version based on the top level assembly for the process (assumed to be the application that is using the SDK).

In such cases, we should require the application to explicitly set the application name and version (using one of UserAgentBuilder.WithApplication(string, string) or UserAgentBuilder.WithApplication(string, Version) instance methods).

This change requires:

• Drop the constructor parameter validation in UserAgentBuilder that checks the applicationAssemblyName parameter is not null - we will need to allow nulls
• Add validation in UserAgentBuilder.BuildUserAgentString() that the application name have been set (either via and AssemblyName or calling the WithApplication() method(s))
• Update docstrings to reflect change (they are nearly right but reviewing them for this change is worthwhile - reviewers 👀 please)
• Raise issues on Enterprise and Scale SDKs to document where the default behavior can be accepted and when it will be necessary to specify the application name and version in setup code