Parameter injection for commands

This adds support for parameter injection with commands.

I don't actually want to merge right away because I want to test a bit more, but I'd like some input (and any objections).

Old vs. new
---------

```java
@Command(
    aliases = { "/set" },
    usage = "<block>",
    desc = "Set all the blocks inside the selection to a block",
    min = 1,
    max = 1
)
@CommandPermissions("worldedit.region.set")
@Logging(REGION)
public void set(CommandContext args, LocalSession session, LocalPlayer player,
        EditSession editSession) throws WorldEditException {

    Pattern pattern = we.getBlockPattern(player, args.getString(0));

    int affected;

    if (pattern instanceof SingleBlockPattern) {
        affected = editSession.setBlocks(session.getSelection(player.getWorld()),
                ((SingleBlockPattern) pattern).getBlock());
    } else {
        affected = editSession.setBlocks(session.getSelection(player.getWorld()), pattern);
    }

    player.print(affected + " block(s) have been changed.");
}
```

becomes a more manageable

```java
@Command(aliases = "/set",
         desc = "Set all the blocks inside the selection to a block")
@CommandPermissions("worldedit.region.set")
@Logging(REGION)
public void setBlocks(LocalPlayer player, EditSession editSession,
        @Selection Region region, Pattern replaceWith) throws MaxChangedBlocksException {
    int affected = editSession.setBlocks(region, replaceWith);
    player.print(affected + " block(s) have been changed.");
}
```

Complex constructs
---------

You can also use more complex constructs.

```java
public void smoothen(LocalPlayer player, EditSession editSession,
        @Selection Region region,
        @Optional("1") @Range(min = 1) int iterations,
        @Switch('n') boolean onlyNaturalBlocks)
    // ...
}
```

which results in `//smooth [-n] [<iterations=1>]`

Backwards compatibility
---------

Old-style commands are not known to the new code, but they work just fine. They are processed using the same framework as with the "newer" approach.

```java
void biomeList(CommandContext args, LocalSession session,
               LocalPlayer player, EditSession editSession)
```

However, `usage =` (and other relevant properties) must be defined on `@Command` otherwise usage information would be unavailable.



Bindings
---------

Adding support for a new type of parameter is easy.

```java
@BindingMatch(type = Pattern.class,
              behavior = BindingBehavior.CONSUMES,
              consumedCount = 1)
public Pattern getPattern(ArgumentStack context) 
        throws ParameterException, WorldEditException {
    return worldEdit.getBlockPattern(getLocalPlayer(context), context.next());
}
```

Exception handling
---------

Previously, non-command related exceptions were handled in an ugly big try-catch that couldn't be 'reused' anywhere else. Now it's stored off in a reusuable class.

```java
@ExceptionMatch
public void convert(IncompleteRegionException e) throws CommandException {
    throw new CommandException("Make a region selection first.");
}
```

Invocation listeners
---------

WorldEdit has an annotation-based logging mechanism, and this was handled by overriding the method performing the invoke() call. Now it's much cleaner, and you can mix and match modules.

```java
builder.attach(new CommandPermissionsHandler());
builder.attach(new WorldEditExceptionConverter(config));
builder.attach(new LegacyCommandsHandler());
builder.attach(commandLogger = new CommandLoggingHandler(this, config));
```

Better responses
---------

Before, we had to define `usage = "var1 var2 [var3]`" by hand, but that was annoying and it could become out of date if the command was changed but the annotation wasn't. Now the new command builder generates these usage strings automatically and uses the names of the parameters (in the source code) to fill in parameter names.

It also provides generally better responses if you type too many arguments or too few. Each argument parser can also throw its own exceptions and present detailed error messages.

Auto-complete
---------

There's also support for generating suggestions dynamically (for when you press TAB to auto-complete) but I'm currently not using it and it needs some minor work first. For example, if you pressed tab on `n` for a direction, it could complete it to `north`. No work is needed on part of the command.