Add generated error types for convenience

[adamthom-amzn]

Description of changes:

It's really annoying to throw objects that have a bunch of fixed values. This turns:

        const e: NoSuchResource = {
            name: "NoSuchResource",
            $fault: "client",
            resourceType: "Venue",
            $metadata: {}
        };
        throw e;

into

        throw new NoSuchResourceError({resourceType: "Venue"});

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[JordonPhillips]

Should add a comment explaining why this is here, particularly when it's not being done for clients.

[adamthom-amzn]

okay, I added it

[JordonPhillips]

Is suffixing errors being used to get around having to alias the error interface? It would probably be better to construct a SymbolReference for the error like so:

SymbolReference symbol = SymbolReference.builder()
    .symbol(errorInterfaceSymbol)
    .alias("__" + errorInterfaceSymbol.getName())
    .build();

Of course you could also do:

String errorInterfaceAlias = "__" + errorInterfaceSymbol.getName();
writer.addImport(errorInterfaceSymbol, errorInterfaceAlias, SymbolReference.ContextOption.USE);

And then manually pass around the name string, which is effectively what the SymbolReference gives you.

[adamthom-amzn]

This is to work around the fact that we can't export the type from models and then export a type of the same name here. Honestly, it works out; instead of throwing new ResourceNotFound(), you throw new ResourceNotFoundError(), and people will probably figure out that they don't want to postfix their error structure names with Error.