Support dependency isolation and/or conflicting versions

Project should be refactored to allow gadgets/chains to be generated (and unit tested) with only exactly the exact required dependencies and versions, even in cases where two different gadgets/chains require a different version of the same library (See #16). This should also reduce the likelihood of unintended classes or dependencies accidentally leaking into the payloads.

The already included jboss shrinkwrap should suffice for runtime dependency management. Make sure dependencies for gadget chains can still be bundled in the jar somehow.

It is also a goal to keep the project build and code as simple as possible for people to contribute gadgets/chains.
#### Option 1: Reflection

Write or use a reflection DSL that can be used by payload generation code that can use gadget classes dynamically instead of using statically linked code.

Something like [jOOR](https://github.com/jOOQ/jOOR) might be useful for reflection.

**Pros:** Simple build process
**Cons:** Convoluted reflection-based payload generation code
#### Option 2: Maven/Build Voodoo

Split up project into multi-module with aggregator project to generate all-in-one jar. Gadgets/chains can go into an arbitrary number of separate sub-projects according to any dependency version conflicts.

**Pros:** Simple, statically linked payload generation code
**Cons:** Convoluted, splintered build process

Start by reviewing the existing JBoss ShrinkWrap dependency-management setup and how gadget chains are bundled into the jar. Compare the reflection DSL and Maven multi-module options described in the issue; the work is done when chains can use isolated dependency versions, avoid accidental payload leakage, and remain simple to build and test.

Written by the indexing model from the issue text.