Creating skeleton of driver configuration files

Client can submit a Job through REST API. For that, they need a serialized driver configuration file. In .Net/Java hybrid driver (see REEF-51 for a description of that), today the driver config file is created in Java JobClient, that is inconvenient for the clients.
 
This PR is to address this issue. It generates a skeleton of the driver configurations which only contains java configuration settings. This would leave flexibility to the client so that they can deserialize the driver configuration, and set additional parameters and then serialize the result into driver config file again.  

To make the configuration modularized, we also separate HttpServer configuration and NameServer configuration from driver configuration file when creating the skeletons. They would become building blocks. Client can choose what they want in the driver and merge them as need. This would make Http Server and Name server become optional instead of build-in in a .Net/Java hybrid driver. 

The driver skeleton configuration creation is built in pom file so that we can always get the latest config files on the fly. The config files generated are packed inside the jar file for clients to consume.

The PR added additional constructors for JobDriver (bridge) to make HttpServer and NameServer optional during the injection. 

This is for issue: https://issues.apache.org/jira/i#browse/REEF-54?filter=-1

The organization here seems wonky. I understand that the code started as a copy of the `DistributedShell` example, but maybe it is time for a serious cleanup: Why, for instance, is the http configuration code in `JobClient` when there never is a (java) client in REEF.NET?