Add CRC64 and new PackageNamingPolicy

[jonathanpeppers]

Context: dotnet/android#1580

FIPS-compliant Windows 10 machines will throw an exception if the
System.Security.Cryptography.MD5 class is used. We are not using
this for cryptography, but for naming collisions in Java package
names.

Therefore we can switch to using CRC64 instead of MD5. A simple
implementation using a lookup table will suffice for our purposes.

I also expanded the enum:

enum PackageNamingPolicy {
    LowercaseHash = 0,
    Lowercase = 1,
    LowercaseWithAssemblyName = 2,
    LowercaseMD5 = LowercaseHash,
    LowercaseCrc64 = 3,
}

It will currently default to MD5 as before, but can be changed to
LowercaseCrc64 as needed. At some point we might also change the
default value of LowercaseHash.

Further changes will need to be made upstream in
xamarin/xamarin-android to replace (or make optional) usage of MD5
vs CRC64.

[jonpryor]

@jonathanpeppers: one thing to be aware of is that at present, the xamarin-android repo does not set the JavaNativeTypeManager.PackageNamingPolicy property within Mono.Android.dll. As such, on-device execution always uses (PackageNamingPolicy) 0, which just happens to be PackageNamingPolicy.LowercaseHash, but isn't after this PR...except for the default case, which causes 0 and PackageNamingPolicy.LowercaseHash to have the same meaning.

Which means we should hit a scenario in which the Java Callable Wrappers have crc prefixes, while the runtime Reflection fallback code will use md5 prefixes.

There be integration dragons here. :-)

Worse, integration dragons you might not even see, because default environments should use the typemap files, which prevent use of the Reflection fallback path...

Until you use the Designer? :-)

[jonathanpeppers]

I did actually misnumber the enum, it should have started at 0.

So this PR by itself shouldn't break anything, until I try tampering with setting PackageNamingPolicy in xamarin-android.

[jonpryor]

Context: dotnet/android#1580
Context: https://user-images.githubusercontent.com/24926263/38981221-7e0bf7c4-43dc-11e8-8f16-9b6d284a55fb.PNG
Context: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing

[jonpryor]

Commit message:

Context: https://github.com/xamarin/xamarin-android/issues/1580
Context: https://xamarin.github.io/bugzilla-archives/15/15205/bug.html#c1
Context: https://xamarin.github.io/bugzilla-archives/16/16826/bug.html

`JavaNativeTypeManager` [uses MD5 to generate package names][0] for
Java Callable Wrappers, using the hash of the namespace name and the
containing assembly name to produce the Java package name.  This was
because it's perfectly valid for there to be *multiple*
`Example.Name` types within a .NET application, so long as they're
in different assemblies:

	// Lib1.dll
	namespace Example {
	    public class Name : Java.Lang.Object {}
	}

	// Lib2.dll
	namespace Example {
	    public class Name : Java.Lang.Object {}
	}

Because the (default) Java package name is a hash of the namespace
and assembly name, both of these `Example.Name` instances can coexist
because they get separate Java types,
`md5fcf4c1986bf17f9628efcaae404b0b1e.Name` (`md5(Example:Lib1)`) &
`md59dee366f823d92fb98288dda3e25ec49.Name` (`md5(Example:Lib2)`).

This was *never* done for cryptographic purposes.  This was only done
to reduce the likelihood of type name collisions.

Unfortunately, this use of MD5 results in an inability to use
Xamarin.Android on FIPS-enabled machines, because when the **System
cryptography: [Use FIPS compliant algorithms][1] for encryption,
hashing, and signing** setting is enabled on Windows:

!['Use Fips compliant algorithms' setting][2]

then the `System.Security.Cryptography.MD5.Create()` method will
throw `InvalidOperationException`.

In order to support FIPS-enabled machines, use a 64-bit
[Cyclic redundancy check][3] algorithm (CRC64) to instead generate
the Java package names, e.g. `crc64aae7d955a89b38db.Name` and
`crc64217c8705f00a5054.Name`.  A sim:ple implementation using a
lookup table will suffice for our purposes, ported to C# from:

	https://github.com/gityf/crc/blob/8045f50ba6e4193d4ee5d2539025fef26e613c9f/crc/crc64.c

The use of CRC64 avoids the use of MD5, thus permitting execution on
FIPS-enabled Windows machines, and also results in *shorter*
directory names -- as the Java package name is a directory name --
which helps reduce Windows `MAX_PATH` issues.

I also expanded the enum:

	enum PackageNamingPolicy {
	    LowercaseHash = 0,
	    Lowercase = 1,
	    LowercaseWithAssemblyName = 2,
	    LowercaseMD5 = LowercaseHash,
	    LowercaseCRC64 = 3,
	}

Behavior still defaults to `MD5`, as before, but can be changed to
`PackageNamingPolicy.LowercaseCRC64` as needed.

Eventually we will change the default behavior to `LowercaseCrc64`,
and use of MD5 entirely removed.

Further changes will need to be made upstream in
xamarin/xamarin-android to fully integrate support for CRC64.

[0]: https://github.com/xamarin/monodroid/commit/eb04c91c3f202d369c8a2930462ebff4f48b2e3e
[1]: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing
[2]: https://user-images.githubusercontent.com/24926263/38981221-7e0bf7c4-43dc-11e8-8f16-9b6d284a55fb.PNG
[3]: https://en.wikipedia.org/wiki/Cyclic_redundancy_check

[jonathanpeppers]

Commit message looks good, although I changed it to PackageNamingPolicy.LowercaseCrc64.

Let's see if the tests pass? Hopefully I didn't mess something up.