Add tests to check Memory<T>.Slice doesn't reset the high-bit in length

[ahsonkhan]

Addendum to #29246

cc @stephentoub, @GrabYourPitchforks, @joshfree, @KrzysztofCwalina

[stephentoub]

We've been trying very hard to avoid using InternalsVisibleTo. We've been stamping them out across the product assemblies where they've existed, and are resisting adding more.
cc: @weshaggard

[stephentoub]

Instead of doing this, could we just Unsafe.As to reinterpret cast the Memory<T> with a copy in the tests that has the same layout but that has public fields?

[stephentoub]

(Note, too, that I believe InternalsVisibleTo will prevent the linker from trimming away dead code, including that GetObjectStartLength method added purely for testing purposes.)

[ahsonkhan]

We've been trying very hard to avoid using InternalsVisibleTo.

Why are we doing this?

We still added InternalsVisibleTo in some places, like Pipelines.

[GrabYourPitchforks]

@stephentoub That's an interesting point re: the linker and something I don't think we'd previously considered. Thanks for the Unsafe.As tip!

[stephentoub]

Why are we doing this?

There are technical reasons, like preventing cruft in product assemblies we ship, allowing the linker to do its job, etc. There are meta reasons, like encouraging developers to test as best as possible via public API surface rather than taking the easy way out and testing internals directly, designing tests in a way that are overly coupled to implementation that makes them less portable across implementations, etc. And there are philosophical reasons, like wanting tests to best mirror code that customers can write. There will always be situations where a test really needs access to something to fully exercise things the way we want, and for those limited situations we can find workarounds like Unsafe.As, private reflection, etc., with it being a very conscious and deliberate act to take such a dependency, rather than accidentally using an internal because it happened to be exposed, etc.

[weshaggard]

@stephentoub hit the major points, see https://github.com/dotnet/corefx/issues/1604 where I've stated similar opinions in the past.