Load ukernel bitcode as executable_object at the time of lowering to ukernels.

[bjacob]

1. Moves the time of loading ukernel bitcode from serializeExecutable to the GPULowerToUKernels pass.
2. The determination of whether an op can lower to a ukernel, is now based on whether the expected bitcode file is found. This allows removing several utility functions that implemented similar logic in different places.
3. The GPULowerToUKernels pass searches for existing bitcode in a hal.executable.objects attribute, and only loads the embedded ukernel bitcode if that wasn't found, and in either case ensures that that resulting ukernel op has a hal.executable.objects attribute containing the necessary IR. This has several nice implications:
   • The IR becomes completely self-contained: a ukernel op is no longer an opaque interface to some bitcode at-a-distance.
   • This solves the problem of allowing contributing one's own bitcode from the outside. Users can write their own hal.executable.objects.
   • De-duplication of bitcode is handled by the HoistExecutableObjects pass.
   • Linking bitcode is handled by generic linker code linking executable objects.
     • The only useful custom handling of ukernel symbols, was adding AlwaysInline function attributes. This PR moves these attributes to the ukernel source code: [[clang::always_inline]]. I verified that these result in the expected alwaysinline in the bitcode.
4. The ukernel bitcode is part of the ROCM plugin. The serializeExecutable implementation, which was the consumer of that data, is also in the ROCM plugin. But the GPULowerToUKernels pass, which is the new consumer, is outside of that plugin. So this required creating a mechanism to export such embedded data files from the ROCM plugin to the outside. That is solved by the new EmbeddedDataDirectory utility.

[kuhar]

LGTM % nits

[raikonenfnu]

Overall refactoring looks great! just minor Q