ServerConfig and ClientConfig

[Ayiga]

These modifications allow for a lot more robustness when creating handlers or clients.

By allowing for users to specify an explicit ServerConfig or ClientConfig when creating the various Endpoints of the packages, they can customize all of the configurations for each piece in a single area.

I've also taken this opportunity to clean up stuttering of the generated layers in order to pass linting rules, and to hopefully make things more clear.

The renaming of the functions means that the old function names will likely be broken for anyone who was used to how that worked.

In order to ensure as painless of a transition as possible, I've created this merge request from a separate branch. This should give people some time to make any changes if they'd like, or to tag a specific commit to the master branch, if they do not wish to have these changes.

I'm also planning on modifying the generated endpoint name templates to just be the method name instead of servicename/methodName, unless anyone has any major objections. The reason I am going to go for this change is that these changes can allow for github.com/gorilla/mux.Router in place of the standard net/http.DefaultServeMux, and this gives users far greater control of the path prefix than I can. In this vein, in order to accommodate an arbitrary Path Prefix for URL requests, the ClientConfig has an option for such. Unfortunately, it can't be more complicated than a path prefix at the moment. Perhaps that's something for the future with another gorilla adapter of sorts.

[Ayiga]

The travis-ci build wasn't configured at all, so that's why this has failed checks. :\

[Ayiga]

I'm planning on merging the request on Monday. That way it's not in danger of interrupting anyone's build process over the weekend.