[opentitantool] Investigate manifest extension handling

### Description

Currently, opentitantool has a bit of a "split-approach" to handling manifest extensions.

1. There is a table in the manifest structure that declares whether or not certain extensions are likely to be present. In the hjson representation, this is represented as a list of strings with the extension name.
2. The table has pointers to locations in the binary image where the extension data are located. In the hjson representation, this is a separate file that maps extensions to their data (either by raw data bytes or by path reference).

This means manifest handling for extensions at the tooling level involves duplicating extension info between two sources. I seems a bit more straightforward to me that the two hjson files should be merged into a single representation.

Example:
```
{
rsa_modulus: "...",
version_major: "1",
version_minor: "0",
max_key_version: "5",
extensions: {
"spx_key": "/foo/spx_key_0.pem",
"spx_signature": "foo.spx-sig",
"0xbeef": {
identifier: "0xabcd",
value: "01234567",
}
},
}
```

There may need to be some special identifiers that mean "allocate space for this extension; I'll provide the data later" so that spx_signatures can be declared. We'll also have to think about how to deal with unknown extensions.

I realize the current manifest implementation in opentitantool is designed to be directly convertible between the json representation and the C binary representation.

We should consider whether or not the hjson representation for extensions should be unified into the main manifest hjson representation.

Begin by reviewing opentitantool's current manifest implementation and the two HJSON representations described in the issue. Determine whether a unified representation can preserve conversion to the C binary format, including deferred data allocation and unknown extensions; done requires a settled design rather than a single localized edit.

Written by the indexing model from the issue text.