Consolidate direct paths of NativeLibrary API to managed implementation

[huoyaoyuan]

Taking NativeAOT implementation and adapting coreclr behavior. The remaining code for P/Invoke resolver isn't changed.

Mono implementation can be update too, but I'm unsure about how the fallback registered for wasm should be handled.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[jkotas]

Would it be better to split this into unifying NativeLibrary_LoadFromPath/NativeLibrary_FreeLib/NativeLibrary_GetSymbol in one straightforward PR, and do the policy-heave APIs in a separate PR that is unlikely to be straightforward and that will need very careful review?

[huoyaoyuan]

Yeah I think so. The detailed behavior of LoadBySearch are not exactly the same. If we feel too complex we can also keep it unmanaged for coreclr.

[jkotas]

Thanks! @AaronRobinsonMSFT @jkoritzinsky Could you please review this as well?

[AaronRobinsonMSFT]

@elinor-fung or @agocke Do you know if the hosting test legs were triggered above?

[elinor-fung]

Do you know if the hosting test legs were triggered above?

Yes - they are in the Installer_Build_And_Test legs. For example: osx-arm64 Debug Installer_Build_And_Test shows the 'Send to Helix' step kicking off tests that successfully ran.