[NativeAOT-LLVM] Remove the workaround for CalendarData.EnumCalendarInfo

[SingleAccretion]

The functions need real implementations. Opening an issue for tracking purposes.

Code references:

runtimelab/src/coreclr/tools/Common/TypeSystem/IL/ILImporter.cs

Lines 953 to 969 in 8284a6d

	// TODO-LLVM: look for a WASI random function; investigate ICU and EnumCalendarInfo
	public static MethodIL ReplaceStubbedWasmMethods(MethodDesc method, MethodIL methodIL)
	{
	// stubs for Unix calls which are not available to this target yet
	if ((method.OwningType as EcmaType)?.Name == "Interop" && method.Name == "GetRandomBytes")
	{
	// this would normally fill the buffer parameter, but we'll just leave the buffer as is and that will be our "random" data for now
	return new ILStubMethodIL(method, new byte[] { (byte)ILOpcode.ret }, Array.Empty<LocalVariableDefinition>(), null);
	}
	if ((method.OwningType as EcmaType)?.Name == "CalendarData" && method.Name == "EnumCalendarInfo")
	{
	// just return false
	return new ILStubMethodIL(method, new byte[] { (byte)ILOpcode.ldc_i4_0, (byte)ILOpcode.ret }, Array.Empty<LocalVariableDefinition>(), null);
	}
	return methodIL;
	}

runtimelab/src/coreclr/jit/llvmcodegen.cpp

Lines 23 to 32 in 8284a6d

	// mono does this via Javascript (pal_random.js), but prefer not to introduce that dependency as it limits the ability to run out of the browser.
	// Copy the temporary workaround from the IL->LLVM generator for now.
	if (!strcmp(mangledName, "S_P_CoreLib_Interop__GetRandomBytes"))
	{
	// this would normally fill the buffer parameter, but we'll just leave the buffer as is and that will be our "random" data for now
	llvm::BasicBlock* llvmBlock = llvm::BasicBlock::Create(_llvmContext, "", _function);
	_builder.SetInsertPoint(llvmBlock);
	_builder.CreateRetVoid();
	return;
	}

[SingleAccretion]

I am working on #2165 and the last warning to be dealt with is the missing symbol for dotnet_browser_entropy, which is referenced by System.Native now. I see two possible solutions:

1) Properly plumb the JS through our build and use it.
2) Add another workaround (either in compiler or System.Native) to silence the warning.

I like doing 1 now more because:
a) It means we get properly working random data.
b) The concern that we'll tie ourselves to JS-providing WASM hosts seems to no longer be as relevant, as upstream is adding support for WASI builds directly into System.Native, so, presumably, we'll be able to pick that up as well.

@yowl what do you think?

[yowl]

Yes, makes sense, i.e. point 1