Kelp: allow multiple instances of an app

[aeruder]

Kelp generally loads modules, loads config, etc. all in the context of
a specific instance, but the entire module system is setup to load
class-wide methods.

Even a very simple program like the following dies:

use Kelp;

Kelp->new;
Kelp->new;
# Redefining of Kelp::config_hash not allowed at Kelp.pm line 105.

This means you couldn't, for example, load two instances of a Kelp app
with different configs (at least not without creating subclasses).

This commit moves registered methods to a per-instance hash and
overrides AUTOLOAD and can to hook them up. This change should
largely be backwards compatible unless class methods were being loaded
with the module system.

[aeruder]

This changes how registered methods work pretty significantly - there are a couple other approaches too, but thought I'd start with this to open some discussion.

In my application, I'm using Kelp to help with mocking of external services in tests - in some situations I'd like to instantiate two copies of the Kelp microservice with different configuration - but it turns out that right now you just can't ever instantiate a second Kelp app at all.

[bbrtj]

Another reason for this change is the ease of access to autoloaded subs and replacing them without symbol table manipulation and turning off strictness.

I've lately created a module to allow changing the methods introduced by the modules: https://github.com/brtastic/perl-kelpx-hooks/blob/master/lib/KelpX/Hooks.pm#L26
This is a bit messy but it works, it has to replace subs with other subs just before build() is invoked. Would be much, much easier to just replace a record in registered_methods hash, probably even no need for my module other than syntactic sugar / default way of doing that.

Of course, it'll be no longer possible to say MyKelpApp->json anywhere to get a JSON decoder for example, so ultimately the change can break some poorly-written code

[sgnix]

Implemented in a more backwards compatible way in #71