CBST2-02: Make proposer commitment signatures unique to modules

[jclapis]

Requires #310 to be merged first

This is a large change that modifies the ways proposer commitment signatures are generated. Currently, the requesting module isn't embedded into the data being signed so any authorized module can request the signature of any data - including data that might be used or expected by other modules. This PR precludes that possibility by embedding a new special per-module signing ID into the data being signed.

The signing ID is a 32-byte hex string provided in the Commit Boost configuration's [[modules]] section, per module. Module authors can make it whatever they want, and should publish it within their own documentation so users know which unique value to configure for that module. Since Commit Boost doesn't (and won't) maintain a global registry of such IDs, the onus is on the user to ensure the correct ID is entered for each module. Module authors can then directly bake this into their module code, in their signature validation routines, to confirm that any proposer commitments returned by the signer used the correct ID.

Since different modules will have different signing IDs (a condition enforced by the loader logic), this prevents one module from "forging" a signature destined for another one.

Using a discrete signing ID means module authors can change their module ID at any time (such as with a version number bump or a vendor rename) without invalidating previous signatures. Conversely, if they do want to invalidate previous signatures while retaining the module ID, they can do so by simply changing their signing ID and informing their clients to update with the new configuration accordingly.

This also adds new round-trip integration tests that confirm signing works as expected with the new paradigm and cross-module signatures are no longer possible.

Finally, it starts some documentation on how to request proposer commitments from the signer service, including how to request a signature and verify it. See docs/docs/developing/prop-commit-signing.md.

⚠️ This is a breaking change that will invalidate any existing proposer commitment signatures. Once this is added, clients using the signer module will need to be informed of the breaking change and adapt their signature verification routines with the new logic.