NS2.0 AssemblyName.ReferenceMatchesDefinition() (dotnet/coreclr#10919)

NS2.0 AssemblyName.ReferenceMatchesDefinition() (dotnet/coreclr#10919)

This api was broken from its debut in 2.0 (and yet somehow
scored a 2.9% on .NET api catalog)

 https://connect.microsoft.com/VisualStudio/feedback/details/752902/assemblyname-referencematchesdefinition-returns-true-even-though-the-parameters-dont-match

In 2012, the MSDN docs were changed to match its broken behavior:

   Return Value
   Type: System.Boolean
   true if the simple assembly names are the same; otherwise, false.

   Remarks

   The comparison depends only on the simple assembly name. It ignores version, culture, and public key token.

A more accurate description would be:

   This api takes the simple names of the ref and def.
   Then it parses the simple names *as if they were*
   full-blown assembly names with optional Version, Culture
   and PKT (!)

   Then it applies a RefToDef test to that name using a test
   that's quite separate from the one used by the actual
   CoreCLR loader (so any similarities between
   it and the actual binding rules is purely coincidental.)

   Oh, and that code assumes the Def name came from trusted
   sources so if it's has a null Culture property, it NULL-AV's.

We could replicate this behavior on CoreRT (relying on
its own AssemblyBinder) but the more I progressed, the
more the venture failed to pass the laugh test (though
at least we got a nice AssemblyBinder cleanup
as a side effect.)

So what we'll do is make the api behavior match the
MSDN description (and likely come close enough to the compat bar)
but in a more straightforward fashion.

(The RefMatchesDef routine is used on one case - to
match assembly refs against a list of friend-access
assembly defs. So it's not quite dead code though
it probably should be.)

Commit migrated from https://github.com/dotnet/coreclr/commit/f1f5986528158533874cd1f4d4a90a15a374d68b