Compiler stack: Protect loadGeneratedIR from contracts that cannot be deployed

[clonker]

If a contract is not deployable (ie interface / abstract), no yulIR will be generated. This causes the object parser to error out in loadGeneratedIR, as it expects object {} as a bare minimum, but gets an empty string instead.

[r0qs]

I would also add a test case like:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.0;

abstract contract C {
	function f() public virtual returns (string memory);
}

and

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.0;

interface I {
	function f() external returns (string memory);
}

Could be similar to our current ast ir command-line test (https://github.com/ethereum/solidity/blob/e8b5ca83f37b6a126db6a0a1dcfa00decff63647/test/cmdlineTests/ast_ir/args). And also one, or more, for standard Json output (https://github.com/ethereum/solidity/blob/e8b5ca83f37b6a126db6a0a1dcfa00decff63647/test/cmdlineTests/standard_ir_ast_requested/input.json):

{
	"language": "Solidity",
	"sources":
	{
		"C":
		{
			"content": "// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.0; abstract contract C {}"
		}
	},
	"settings": {
		"optimizer": {
			"enabled": true,
			"details": {
				"yul": true
			}
		},
		"viaIR": true,
		"outputSelection": {
			"*": {
				"*": ["irAst", "irOptimizedAst", "yulCFGJson"]
			}
		}
	}

}

[cameel]

Good catch. Looks like I unwittingly introduced this bug in the last release via #15451.

The fix is not wrong, but I'd do it differently in CompilerStack to make this kind of mistake harder to make in the future.

[r0qs]

I have only one suggestion. But it looks good to me anyway :)

[ekpyron]

This should probably also get a bugfix changelog entry. A bit annoying that this is in the release now, but I guess people rarely use these json artifacts anyways - might be a good indicator for how much they're used in the wild actually (since if they're used, people will quickly run into this I guess)