Allow adding instructions dynamically using Java SPI

[BlazingTwist]

Depends on #106
WILL cause merge conflicts with #107

GitHub seems to be confused about the changes made to the *InstructionStore classes.
The only change for all of them is:

• change NamedInstructionStore from an abstract class to an interface
• replace addInstruction calls with Arrays.asList
  The Instructions themselves did not change.

---

What this does

This change allows users to add named instructions without compiling aya itself.

Adding named instructions is done by placing libraries in <ayaDir>/libs/.
Here is an example project that registers 2 additional NamedInstructionStores.
AyaSpiExample.zip
(simply run mvn package and place the jar in the libs directory)

The added instructions behave like any other instruction:

Instruction Name Conflicts

Conflicts (instructions with the same name) are currently handled by using the last registered instruction.
So libraries can override builtin instructions (not sure if that's a good thing)
Aya will print a warning like this:

NamedInstruction 'json.loads' has multiple implementations:
  aya.ext.json.LoadJSONInstruction
  example.spi.ExampleInstructionStore$1

---

Future TODO

Publishing Aya to a Maven repository

Currently, to reference Aya in a libraries' pom.xml (like this:)

<dependency>
    <groupId>co.npaul.aya</groupId>
    <artifactId>aya</artifactId>
    <version>4.0.0</version>
</dependency>

you have to install aya to the local repository by running mvn install.

Ideally, releases would be available from a public repository.
For example: the central repository

Dependency Management

If Aya projects start depending on libraries, this could cause some frustrating Syntax Error: Named instruction :{...} does not exist errors.
There should be some way for Aya projects to declare library dependencies.

E.g. by adding String getLibraryName() and ComparableVersion getVersion() to the NamedInstructionStore interface.
Then projects could reference dependencies and possibly version ranges similar to this

---

Alternative Solutions / Extensions

It would also be possible to load .jar libraries at runtime.
E.g. "/path/to/lib.jar" :{library.load}
which could be implemented just like this

That might already solve the 'Dependency Management' issues, since you'd get a more descriptive "file not found" error.

[nick-paul]

Merged with modifications from this PR: #125