[Improvement] Exported hook and validation types

[adam-alchemy]

• The manifest is limited in how it can define plugin functions, since every entry within it is used to add a step to the “installation procedure” - AKA what changes need to be made to the account state. This causes some tricky-to-handle cases when combined with the user-supplied install config fields (dependencies and injected hooks, see [Improvement] User-supplied install config #9): How can a plugin declare a function that it implements, intended to be used for other plugins’ dependencies and/or hooks, without the plugin putting this into the manifest itself as a thing to install? There may not be an opportunity or reason to install a validation function/hook yet, if its purpose is to provide that function to be used by other plugins.
• The plugin could “declare” functions it provides, either in the manifest or somewhere else, that may be used by other plugins as part of the user-supplied install config.
• If we think it is valuable, we could even add install state validation to this, ensuring only known & installed functions are applied via user-supplied install configs.

[jaypaik]

This seems useful, and perhaps an extension of this also covers execution functions. It seems there isn't a good way to declare a dependency on an execution function for the executeFromPlugin use case currently.

We had this before when dependencies were just plugin addresses (ethereum/EIPs#7516), but with the update to change dependencies to FunctionReferences, we now only allow associated functions to be declared as dependencies.

[jaypaik]

Related: #22