Dac plugin refactor: Integrate reveal mapper into node context

Context

This change exposes Dac_plugin.Dac_hash through the Node_context.t. Module's that use the underlying protocol hash can do so by parameterizing over Node_context.t.

For example, one can see how Dac_plugin.Dac_hash.encoding is exposed via Node_context.get_dac_hash_encoding function. N.B. There is some awkwardness with errors - it returns a tzresult which is inconvenient for callers of this api. My preference would be the node blocks and resolves the plugin at least once on startup before daemonize the plugin resolve handler (why don't we do this?). That way, we can assume the state is Ready if it successfully starts up. Update: After speaking with @andrea.cerone, he agreed that this is a good idea. We need to handle the case that the plugin is undefined for a protocol.

Part of : #4688 (closed)

Manually testing the MR

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR