Improve hooks to better support plugins #410
Description
There is a nice system of hooks in place today, which allows subclasses of cmd2.Cmd() to inject code at various places in the command processing cycle. See hooks.rst in the documentation for full details. With the recent introduction of the idea of plugins, there is a possibility of multiple plugins now wanting to inject code into the same hook.
You can do this today by carefully specifying the order of your mixin classes in your subclassing statement, and ensuring you have the proper super() calls in your methods. However, this method is not super intuitive for those who aren't up to speed on the super() chain with multiple inheritance.
I propose we implement a more robust system where a plugin can register functions to be called at various points in the command processing cycle. cmd2.Cmd() would keep track of all the registered functions for each "hook", and then call them in sequence when the "hook" was activated.
This approach also could make it easier to define command processing plugins. All of the command processing hooks would call functions with a similar parameter and return signature, which would mean you could define a plugin function, and insert it into whichever hook you wanted. Moving your function to a different hook would not require you to modify the function, just the hook to which it was registered.
I think we can maintain backwards compatibility with the current method of calling hooks by fixing onecmd_plus_hooks() to call the registered functions for each hook, and then call the hook method (as it currently does). This approach would allow subclasses of cmd2.Cmd() to override postparsing_precmd(), while still using plugins which would also like to perform work in that same hook.