Initial attempt to make proxy generation faster in frames

Frames as a framework uses proxies to implement end user provided
interfaces that apt a basic Pojo style for graph ↔ object access. It
appears from testing frames in heavy usage in a production style
environment with large graphs that the Java proxy overhead is expensive.

As such this commit allows for the proxy generation to be performed with
different "providers" naturally any new strategy has its own particular
merits and difficulties.

For a first implementation the following methods are used:

    ∘ Java Proxies (the default): This works much like frames currently
    ∘ CGLib: Old but gold version of making proxies for java
    ∘ ASM: Direct bytecode proxy crafter

Using the carrotsearch benchmarking module the following performance
stats appear for the different implementations, suggesting that the ASM
version is twice as fast as the java proxy version:

---- %< ----

FrameBackendPerformanceTest.testJavaProxyFrames:
[measured 50 out of 55 rounds, threads: 1 (sequential)]
 round: 2.25 [+- 1.26], round.gc: 0.00 [+- 0.00],
    GC.calls: 27, GC.time: 11.92, time.total: 114.30, time.warmup: 1.78, time.bench: 112.52

FrameBackendPerformanceTest.testJavaCgLibFrames:
[measured 50 out of 55 rounds, threads: 1 (sequential)]
 round: 1.78 [+- 2.01], round.gc: 0.00 [+- 0.00],
    GC.calls: 25, GC.time: 45.92, time.total: 89.96, time.warmup: 0.76, time.bench: 89.20

FrameBackendPerformanceTest.testJavaAsmFrames:
[measured 50 out of 55 rounds, threads: 1 (sequential)]
 round: 0.65 [+- 0.67], round.gc: 0.00 [+- 0.00],
    GC.calls: 12, GC.time: 6.83, time.total: 33.00, time.warmup: 0.54, time.bench: 32.46

---- >% ----

There are still a few things todo namely:

    ∘ A proper set of unit tests for each of the generators
    ∘ A little more work to find hotspots in the ASM generator to make it faster
    ∘ Internalising the ASM dependency