Correctly handle duplicate WellKnownType values

[jaredpar]

The WellKnownType enumeration contains several named items that have the
same underlying value. Both First and Last share a value with an actual
type entry in the enumeration. A ToString call on those values can
return either the type name or First / Last, the runtime does not define
which will happen.

This comes into play in the static constructor of WellKnownTypes where
we assert that the enumeration and s_metadataNames table stay in sync.
The code already accounts for First being ambiguous but failed to for
Last.

This change removes the assumption for Last as well. It also expands
out the assert as it was getting to difficult to follow when I added
another level of ternary expressions into the mix.

[jaredpar]

CC @gafter @AlekseyTs @agocke

[agocke]

I'm not a fan of ifdefs -- any specific reason you chose one instead of a helper method + debug assert call?

[jaredpar]

@agocke because extending the existing Debug.Assert was unreadable. I'm fine with a separate method altogether.

[agocke]

@jaredpar I would prefer refactoring into a helper method, then calling that in Debug.Assert, if you have no objection.

[jaredpar]

@agocke I was just going to have a [Conditional("DEBUG")] method that held the logic.

[agocke]

@jaredpar That works too. Anything that preserves semantic analysis in the compilation regardless of your defined variables :)

[AlekseyTs]

LGTM

[gafter]

If you're going to turn one enum into a particular name, you should assert that they represent the same element, e.g.:

   Debug.Assert(WellKnownType.Last == WellKnownType.System_IFormatProvider);

[gafter]

👍

[agocke]

LGTM