Updating project template design

[fehguy]

The templates have often been a source of issue with this project--between being bundled with the final artifact (requiring a new release for a single change to be picked up) and the waterfall-style "everything updates at once" issue that this creates. With 3.0 support on the way, now is the time to improve the structure to make the templates more maintainable and give more control to end-users.

First and foremost, we need to create a simple, stable interface that all template "packs" must implement. Think of a template pack as the combination of a java class and template files. The java class must implement a stable interface in the main codegen project before it can be discovered and loaded. This interface should continue to live in the main codegen project. One major change in how the interface should work--I would like to see the version become part of the identifier for a template pack, and allow multiple versions of the same template to exist in a single deployment simultaneously. This will help us avoid many of the issues with upgrades. Also template-specific tests should live in the template implementations.

Next, template-specific java classes (i.e. the /languages/*.java files) and the template resources themselves (`/src/main/resources/**) files should move out of this repository. A new repository should be created to hold the templates, and they should be publishable independently, meaning, we won't have to version all templates in this new repository simultaneously.

The POJOs being passed to the templates are far too complicated. This has roots in both legacy (the same structure has evolved since 1.2 support) and that the template engine is logic-less. That has required tons of ugly logic to be added to the pojos like isContainer and isNotContainer and isNotMap, etc. Yuck. The new design of the pojos should be:

• Much more simple. Get rid of the is* / isNot* garbage
• Use the very flexible extension mechanism instead of polluting the pojos. That is, if you need some special handling for a specific language in int values, you can add an extension x-is-integer: true instead of jamming a isInt property in the pojos. We should not take exception to this, or the stable interface from before will never work
• Get rid of mustache and switch to handlebars. This will help address the logic issues from before, and in most cases are backwards compatible with the handlebars templates. I have been experimenting with this library with good results:

        <dependency>
            <groupId>com.github.jknack</groupId>
            <artifactId>handlebars</artifactId>
            <version>4.0.6</version>
        </dependency>

Finally, the pattern we have been using needs to change. Previously, templates tended to follow a single pattern--you get a concrete response (assuming there is a response in an operation) or an error. Well 3.0 adds a lot of complexity to both requests and responses since you can use oneOf and other composition patterns. That, and the fact that you can have different schemas on each media type, means that we no longer can return a single response payload for operations under anything but hello-world-style apis. We'll need to start doing something like this:

Response Wrapper
- Response Headers
- Response Schema
- Response Content-Type
- Status
- Payload

And based on the response schema, the end-user will need to cast or coerce the response into the type that they expect (assuming a typed language).

[wing328]

PR related to handlebars: #5365