Initial implementation of modules doesn't support multiple instances

The following discussion from !632 (closed) should be addressed:

• @michal started a discussion: (+1 comment)

  As for commit 882a62c6, I am afraid it does not solve another high-level issue that has only occurred to me just now: it is impossible to use two instances of a given hook module in separate views, which kind of renders the concept of per-view hook tables bogus :(

  I would consider reverting 882a62c6 and moving to a more complex model that would solve both issues. An example would be:

  • track modules currently in use using a server-wide list; each element in that list would be a reference-counted structure representing a single shared object mapped using dlopen() (that can be released once its reference count drops to 0),
  • introduce hook instances (hey, remember b7a25260? ;)), i.e. make every hook statement present in a configuration grab a reference to the module structure from the previous bullet point and make sure it acts independently from any other hook statements,
  • use instance-specific configuration and data tables in modules,
  • keep per-view lists of hook instances currently registered in that view's hook table.

  I know this hurts, but I do not think we can defend the current approach in the long run due to its very limited flexibility.

  Perhaps we should consider implementing this in a follow-up MR rather than right now. In any case, I think we should address this before making a release with hooks available.