Multi handler support

[jirikuncar]

addresses #18

cc @ibnesayeed

[ibnesayeed]

What if we organize the configs of both types of handlers (named and anonymous) on the same level (i.e., under self['HANDLERS'])? One option is to use a hard coded placeholder handler name for the anonymous handler such as DEFAULT or ANONYMOUS, but this will add special cases in the application.py file and will limit the use of these reserved keywords as handler names. However, there is a cleaner option to use None (not the string "None") as the handler name that will remove special case handling while still organizing all the handlers at the same depth. Here is one possible way to write this (note that I have also added code to deal with the case where a section is names as handler: i.e., ending with a colon, but nothing after that.):

        self.setdefault('HANDLERS', {})
        for section_name in conf.sections():
            parts = section_name.rstrip(':').split(':', 1)
            if parts[0] == 'handler':
                section = build_handler(section_name)
                handler_name = None
                if len(parts) > 1:
                    handler_name = parts[1]
                self['HANDLERS'][handler_name] = section

This will also remove the following line from application.py file:

        self.register_handler(None, self.config)

[jirikuncar]

I had it this way initially, but I changed it to keep the defaults on "global" level, which are easier to override.

[jirikuncar]

I have improved the config handling. The "old" config values are used as defaults for all handlers. One can still keep default values and override the "default" (None) hander:

HANDLERS = {None: {'USE_TIMEMAP': False}}

or

[handler]
use_timemap = False

[handler:]  # see the "trick" with :
use_timemap = True

[handler:simple]
# falls back to use_timemap = False

[ibnesayeed]

@jirikuncar would you mind rebasing this PR to resolve the conflict and verify that it is still working? I am not sure whether it is still being considered in this repo, but I would like to use this feature elsewhere.

[jirikuncar]

@ibnesayeed I have granted access to maintainers to update the PR. Feel free to rebase the code.

[ibnesayeed]

Thanks for the help @jirikuncar. I tried merging like this the other day, but tests were failing after doing so. Also, I am not a maintainer of this repo. While I am in support of bringing multi-handler support to it, people at LANL feel differently. I am not sure if their opinion has changed since our last conversation on this topic. So, I asked for your help for my use of this tool, not for the sake of getting it merged here. I really appreciate your help.