CodeGen: implement the wide architecture set

[ForNeVeR]

Closes #354.

TODO

• Documentation & planning
  • Allow raw pointers as function parameters?
  • CPtr for structure fields
  • CFuncPtr for function pointers in structure fields
• Make sure all the cases described in the documentation are covered by the added tests
• Merge with main
• Review the standard library changes
  • Most of them may be unnecessary since we no longer change the pointers in signatures
• Fix the tests
• Add tests on interop
  • Call .NET function accepting a raw pointer from wide arch
  • Call .NET function accepting a (C|F|V)Ptr from wide arch
• present pointers as long CPtr<T> in codegen on Wide architecture
  • only in structures; see Cesium.CodeGen.Tests.ArchitectureDependentTypeTests.StructWithPointer
  • test for ptr to ptr
• Present function pointers as FPtr on Wide architecture
  • also only in structures
• Accommodate Tests: add a workaround for https://github.com/dotnet/sdk/issues/34653 #440 here
• Add a special InteropType, CLI imports should produce functions with interop types as arguments
  • InteropType knows how to convert a normal type to CLI type
• At this point, all the tests should become green
  • Well, apparently they didn't, but I should make them so
• CodeGenNetInteropTests: add actual run test for CPtr interop
• Add a test for array addressing in the wide arch
• Document the function pointer solution
• standard library enhancement
  • create a CPtr<T> type
  • add implicit conversions
  • add codegen support
  • support CPtr interop
• FPtr interop
• integration test
• Check what's going with __nint
  • Perhaps just don't support it in the wide architecture?
• TODO sweep
• Make sure everything discussed in Wide architecture support #354 is implemented
• Final review

Before merge

• TODO monitoring
  • comments
  • ToDo
• Create an issue on reverse *Ptr interop (e.g. as a function return value, or by pointer)
• Create an issue to turn nint/nuint into long/ulong on the Wide arch

[kant2002]

Maybe FuncPtr?

[kant2002]

And maybe VoidPtr. I do like CPtr, but it sounds too broad for me. But that's just remark. I do have only vague feeling here.

[kant2002]

Not sure if somebody think about it, so I leave it.
Function pointers IMO we whould represent as RuntimeMethodHandle. When convert to void* we can convert to nuint or CPtr and then back. For calls of this method we can use calli.
Approximately like this.
https://github.com/dotnet/runtime/blob/476bce3456006245bdade1fc38a1a300b10f91e8/src/mono/mono/tests/calli_sig_check.il#L13-L21

[ForNeVeR]

My general idea is to preserve the function pointers as function pointers, when possible. And fall back to various strange things (delegates or whatnot) when not.

But importantly, not every function may be presented by a RuntimeMethodHandle: if you got a native function, it may not have a "method" per se.

Cesium interop with native code is a bit of underspecified right now (and that's a pretty generous statement already), but it's a thing we'll want to get better at. Eventually. So, our current design should at least consider how it will work in the future.