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

I understand the need here. But it also destabilizes other users of `DriverConfiguration`: The ID isn't optional, and marking it as such is confusing and error prone. I see two ways out of this:

  1. Make the ID optional. We would have to drop some logic into `JobSubmissionHelper` to generate unique IDs for when the user doesn't specify one.
  2. Keep the ID required, but essentially copy `DriverConfiguration` over here. This isn't pretty, but would localize the change.

What do you think? Which way shall we go?