Feature Request: User-provided ABI for --standard-json (Yul only)

Currently, the `"abi"` output selector is a no-op when `language=Yul`.

This is a problem for yul source verification: while blockchain explorers like etherscan and blockscout support standard-json input for verification, they choke if there is no ABI present in the output (though, as of [blockscout#6444][bs], it looks like blockscout _does_ support yul verification, despite the lack of abi).

Since contracts written in plain Yul have no way to specify an ABI in any manner recognizable to the compiler, it would be nice if solc accepted `abi` as a standard-json input field and simply spit it out on the other side when compiling with `language=Yul` (maybe also validate the json to ensure it matches the schema of a json abi object).

By doing this there's some implications (potential attacks) for explorers that allow source verification via standard-json: e.g. an attacker compiles their solidity contract to yul and source-verifies the very hard-to-read IR instead of the actual solidity code. That said, a similar obfuscation technique is already possible by writing a solidity contract and wrapping the body of every external function inside an `assembly` block (albeit a bit more work).

I might be barking up the wrong tree with this, as it would be "cleaner" to simply beseech the aforementioned explorers to update their API and allow for some kind of `abi` parameter, but adding this very small feature to the compiler itself would _transparently_ fix the problems with all of the explorer sites currently deployed, allowing for Yul source verification.

I suppose this also brings up an ethical concern: this may qualify as a kind of surreptitious soft-fork for explorers, which perhaps adds an undesired feature without their knowledge. Though, they can always explicitly blacklist `language=Yul` if they want to.

In any case, another major benefit of this is that newer languages which compile to Yul do not need to wait for explorer integration. This includes projects like [fe], which uses solc as a backend for the final yul->bytecode codegen step.

[bs]: https://github.com/blockscout/blockscout/pull/6444
[fe]: https://github.com/ethereum/fe

Start by tracing the --standard-json input and output handling for language=Yul, especially the currently no-op "abi" output selector. Review the issue's explorer-compatibility and validation concerns before deciding the behavior. Done means the accepted input and resulting output are defined, covered by tests, and compatible with the intended Yul verification workflow.

Written by the indexing model from the issue text.