[Feature Request] Convert user-provided values to UTF8 and use these to compare with UTF8 values from JWT

[pmaytak]

NET stores 'string' type as UTF16, while an incoming JWT is UTF8. Currently the inefficiency is that we convert the JWT values into UTF16, store them, then preform validation.

• Wherever (TokenValidationParameters) user-provided input (ex. audience, issuer) exists, create an associated internal ReadOnlySpan property of Utf8.
• When reading values from an incoming token, validate the values immediately after reading them and fail fast if validation fails.
• When doing the validation use the Utf8-valued property for comparison rather than a string.
• There could be a large number of custom claims in a JWT, meaning we can't create a property for each. Add an extensibility point, like a user-passed in delegate, which would dynamically validate those custom claims.
• Currently on get, the public properties retrieve the value from the payload. We should instead ToString() the aforementioned Utf8 properties on demand
• Investigate if using Utf8JsonReader.ValueSpan can be used when comparing values.

Benchmark of CompareUtf8 vs CompareUtf16:

Method	Toolchain	IterationCount	RunStrategy	Mean	Error	StdDev	Median	P90	P95	P100	Gen0	Allocated
CompareUtf16	Default	Default	Throughput	223.7 ns	1.14 ns	0.95 ns	223.9 ns	224.9 ns	225.0 ns	225.1 ns	0.0186	312 B
CompareUtf8	Default	Default	Throughput	167.7 ns	0.87 ns	0.68 ns	167.8 ns	168.4 ns	168.5 ns	168.6 ns	0.0072	120 B
CompareUtf16	InProcessEmitToolchain	15	Default	217.5 ns	0.44 ns	0.64 ns	217.6 ns	218.2 ns	218.8 ns	219.1 ns	0.0186	312 B
CompareUtf8	InProcessEmitToolchain	15	Default	174.6 ns	1.78 ns	2.61 ns	173.2 ns	177.9 ns	178.2 ns	179.4 ns	0.0072	120 B

"What we see is about a 25% gain in performance and a greater than 50% reduction in memory."

Related to #2581, #2583.