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

Currently Launch is used for either submitting Reef or generating driver.config file.  NRT uses it for generating driver.config file. And Azure ML uses it for submitting Reef. Also all tests for local runtime uses it for submit. As driver configuration for java part is shared, so I still worked on the same code base to avoid duplication. Once the new way for creating configuration is adopted by the client, we can refactor the code to separate Launch (submit) and config generation as configuration generation by that time will be used by our internal only.