[src/runtime] Add extra checks to Runtime.IsUserType to detect invalid pointers.

[rolfbjarne]

This will hopefully make it easier to diagnose these kinds of crashes:

Thread 0 Crashed:
0   libobjc.A.dylib                      0x00000001a6f6e7f8 object_getClass + 48
1   MyTestDotNetApp.Net                  0x0000000104b90a68 do_icall (interp.c:2273)
2   MyTestDotNetApp.Net                  0x0000000104b8f838 do_icall_wrapper (interp.c:2361)
3   MyTestDotNetApp.Net                  0x0000000104b85214 interp_exec_method (interp.c:3885)
4   MyTestDotNetApp.Net                  0x0000000104b82de8 interp_runtime_invoke (interp.c:2122)
5   MyTestDotNetApp.Net                  0x0000000104b4aedc mono_jit_runtime_invoke (mini-runtime.c:3650)
6   MyTestDotNetApp.Net                  0x0000000104a8b874 mono_runtime_try_invoke (object.c:2415)
7   MyTestDotNetApp.Net                  0x0000000104a8d8a0 mono_runtime_invoke (object.c:2464)
8   MyTestDotNetApp.Net                  0x0000000104c42b68 native_to_managed_trampoline_68(objc_object*, objc_selector*, _MonoMethod**, objc_object*, unsigned int) (registrar.mm:4511)
9   MyTestDotNetApp.Net                  0x0000000104c42a00 +[__NSObject_Disposer drain:] (registrar.mm:20968)
10  Foundation                           0x00000001adc13b14 __NSThreadPerformPerform + 260

This happens because we try to access freed/invalid memory, but unfortunately
the crash report / stack trace does not contain any hint whatsoever about the
memory that triggered the crash.

By adding an opt-in to validate the memory for a given object, we might be
able to detect this crash in a few cases, and instead throw a managed
exception with much more information.

A project opts-in by setting _ValidateObjectPointers=true in the csproj.

Ref: #19493

[dalexsoto]

Should we document this inside our docs folder?

[rolfbjarne]

Superseded by #21001.