Add one more "late metadata"/"digest" file to rlib archives

[petrochenkov]

The file should contain data about:

• Native libraries bundled into the rlib, to avoid looking up native libraries during the regular "early" metadata construction, when it's unnecessary and cannot be done fully correctly (native_libs: More consistent native library search between rustc and linker #138170)
• Object files bundled into the rlib, to support link time cfg on native libraries bundled as object files
• Rust object files in the rlib to avoid hacks like looks_like_rust_object_file during LTO

Unlike regular metadata which is constructed early, this additional digest will be constructed and added to the archive in the very end, when all other members of the rlib archive are already added.
It is also going to be read only when rustc is going to link the rlib into something, not earlier.

The data could potentially use some text format like json, but it would probably be simpler to just use the same format as the regular metadata uses.
The implementation can also mirror what is done for regular metadata, in a simplified form.

Me and @belovdv wanted to do this when implementing +bundle,+whole-archive (#113301) and packed_bundled_libs (#108081), as a more principle solution, but ended up with just some workarounds instead, and never returned to this.

[petrochenkov]

I suggest first adding some data that is enough to avoid the file skipping hacks in fn link_staticlib.

[bjorn3]

Why put it at the end? That would mean we have to scan over each rlib twice during linking. Once to find the "digest" and a second time to copy the actual content. Ar archives don't allow random access. You need to iterate over them one entry at a time. Wouldn't it be possible to create this "digest" during rlib writing before adding object files, but after we already know which object files will be added?

[petrochenkov]

fn link_rlib contains a number of archive_builder.add_file(...); steps.
I assumed each of them would also add something into the digest, then the digest would become ready in the end.

Of course it can be refactored to be a bit smarter as an optimization.

[davidtwco]

You might get more visibility on this as an MCP - it sounds reasonable to me.