[mono] Extend mono AOT compiler to ingest .mibc profiles

[mdh1418]

Part of #69268 and #69512.

In effort to bring back Profiled Ahead-Of-Time compilation on Mono through leveraging EventPipe diagnostics-tracing and CoreCLR's dotnet-pgo tool, this PR enables Mono's AOT Compiler to directly consume a .mibc (Managed Instrumented Block Counts) Portable Executable file generated through dotnet-pgo for the purpose of AOT compiling methods traced during an app run.

This follows the work to emit MethodDetails and BulkType events on the mono runtime, which was imperative to know exactly which methods were encountered during an app run.

---

Prior Profiled AOT .aotprofile processing

Mono's AOT Compiler (mono-sgen) prior Profiled AOT story involved a .aotprofile file which recorded identifying components of methods, embedded types, generic instantiations of methods/types, and the overarching modules https://github.com/mono/mono/tree/main/mcs/class/Mono.Profiler.Log/Mono.Profiler.Aot. The compiler, when compiling particular assemblies, would leverage .aotprofile data to determine which methods to AOT compile by:

1. Loading the data into ProfileData structs
2. Resolving the ProfileData structs into the corresponding images, classes, generic instantiations, and methods within the assemblies loaded through the compiler
3. Adding the .aotprofile methods with some filtering to a particular assembly's (X.dll) AOT image (X.dll.so/X.dll.dylib/other native extensions) if they are inherently from that assembly, or related to that assembly. (e.g. method List<Q>.ToArray() where List is in System.Private.CoreLib.dll, but Q is in Q.dll, the method is related to assembly Q.dll)

.aotprofile example

Proposed Profiled AOT .mibc processing

The .mibc file format as a Portable Executable already contains comprehensive information of traced methods (as a result of MethodDetails and BulkType events from #68571). As such, there is no need to neither generate nor load ProfileData structs. Instead, we:

1. Leverage .mibc's AssemblyDictionary global function to obtain each mibcGroupMethod - add_mibc_profile_methods
2. Iterate through each method entry within a mibcGroupMethod - add_mibc_group_method_methods
3. Add individual .mibc methods using the same filter and method addition used when processing .aotprofile - add_single_mibc_profile_method

.mibc from HelloWorld mono sample
Breakdown of HelloWorld Sample .mibc file

---

This PR makes the following changes:

1. Introduces .mibc profile file into the mono AOT compilation pipeline
2. Extends mono's image handling to allow for loading MemberRefs from non executable images and replace boolean image open/load options with MonoImage(Open/Load)Options structs for scalability
3. Bootstrap the MonoAOTCompiler to use the introduced .mibc processing

---

Using the mono-sgen compiler to process .mibc

1. ./build -s mono+libs -os <OS> -arch <arch> -c <config>
2. MONO_LOG_MASK=asm MONO_LOG_LEVEL=debug MONO_PATH=./artifacts/bin/HelloWorld/arm64/Release/osx-arm64/publish/ artifacts/obj/mono/OSX.arm64.Release/out/bin/mono-sgen --aot=profile-only,mibc-profile=/Users/mihw/runtime_two/HelloWorld_arm64.mibc artifacts/bin/HelloWorld/arm64/Release/osx-arm64/publish/System.Console.dll artifacts/bin/HelloWorld/arm64/Release/osx-arm64/publish/System.Private.CoreLib.dll artifacts/bin/HelloWorld/arm64/Release/osx-arm64/publish/HelloWorld.dll
   

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[lambdageek]

Looking good.

Couple of things i'd like to see changed:

1. let's do some cleanup in image.c
2. let's make the code that iterates over the mibc group a bit more aware of the format
3. instead of copy/pasting the AOT "related methods" logic, extract it into a function and share between the mibc and legacy aot profiler

[lambdageek]

LGTM. A couple of nits, some portability improvements, and a bit more image_open refactoring suggestions

[lambdageek]

Suggested change

	guint32 token = *(guint32 *)(opcodeIp + 1);
	guint32 token = read32 (opcodeIp + 1);

[mdh1418]

Thanks! I thought it would work, but convinced myself it didnt when xcode lldb complained about expr read32 (opcodeIp + 1). Is there a way to have the xcode lldb recognize methods such as read32?

[lambdageek]

I think if you compile the runtime with "enough" debug information (maybe -g3) then debuggers ought to recognize macros like read32. not sure if that really works with clang+lldb

[mdh1418]

The failures are unrelated to this PR and have issues created.

[lateralusX]

Any specific reason why these parameters where inverted compared to the arguments passed to functions below?

[lateralusX]

Any particular win to use bit fields for this? I think it would be much clearer to use bool type instead, it would also make the init code more clear.

[lambdageek]

Any specific reason why these parameters where inverted compared to the arguments passed to functions below?

Turns out most of the time we care about cli and pecoff, so the callers become a bit simpler: they can just initialize the options struct to zero.

Any particular win to use bit fields for this? I think it would be much clearer to use bool type instead, it would also make the init code more clear.

I think I suggested bitfields more out of habit than any rational reason. These could be booleans.

[mdh1418]

Thanks! I'll modify these to a boolean type in the upcoming PR

[lambdageek]

(the MonoImage:not_executable we do want to keep in a bitfield - we try to keep the size of that structure down)

[mdh1418]

This is now in PR #71657 @lateralusX @lambdageek