Offer unsurpising build behavior

[ypapadop-amd]

I'm creating this issue to track the expectations and behavior for the build process that is used with JIT and when integrating IRON with external projects.

There are currently two PRs that address two cases of the same issue, the inability to have a single object file that combines all the required core function implementations.

1. Add a code object cache for external functions #2509 establishes that two ExternalFunctions should share a single object file instead of generating two different object files with the same symbols. It relies on the user providing a single implementation and automatic hashing to detect multiple definitions.
2. Combining multiple object files in JIT #2530 uses information from the ExternalFunction objects to build a single object file from multiple object files. It assumes that there are no duplicate symbols in the object files.

The two approaches are complimentary, but they still fail to address more complex scenarios such as the following:

Inline functions in ExternalFunctions that produce a single object file with multiple symbols that each is bound to its own ExternalFunction object are also permitted.

The implementation for all this is mostly there, since we already have

1. file-based and inline definition of functions,
2. implicit or explicit definition of object file names, and
3. function that combines multiple object files.

What we are still missing is a way to create multiple ExternalFunction objects from a single source, i.e., ExternalFunctions above (or module, compilation unit, archive, etc.).

The JIT workflow can use this by adding an additional step of hashing the MLIR module and the different source codes and compilation flags (which it already does to some extend). Other workflows that integrate IRON could use it by reusing the function definitions and the handles to functions (ExternalFunction objects), the source code compilation and linking functions and only have to deal with the produced artifacts.

[ypapadop-amd]

cc @mawad-amd @jgmelber

[stephenneuendorffer]

I'm somewhat concerned that the complexity of this will continue to creep to describe arbitrary compilation and linking...

[ypapadop-amd]

I agree, this becomes more of an ad-hoc build system rather than anything else. On the other hand, we already have examples where the existing support fails or we are lead to anti-patterns (e.g., including .cpp files).

If we're willing to set an arbitrary set of constraints, we would drastically reduce the requirements. E.g., I think that forcing a single exported symbol per object file and common functions / arrays being header-only, it would enforce a single source file per ExternalFunction.