emit thread, config file, unit tests

The changes should have no effect on the people who are currently using this, if they do not change anything in their code. 

I added the followings:

- an auto-emit feature, disabled by default. the way to use this is through one of the added constructors, e.g.:
Client(String programId, boolean autoStatEmit, boolean clearStatAfterEmit, int statEmitInterval). 
the old constructor where we only pass the programId will have this feature disabled. 

- config file to read mondemand addresses/port from. e.g.:
client.addTransportsFromDefaultConfigFile() or client.addTransportsFromConfigFile(config_file)

- a timer stat where we could specify extra attributes to be emitted for it. e.g.:
client.incrementTimer("key", some_value, TimerStatTrackType.MIN | TimerStatTrackType.MAX | TimerStatTrackType.MIN.PCTL_98 
this will emit min,max and 98 percentile of the values added to the counter since the last emission of the counter. 

I also added unit tests for the added/modified codes. 
I could change this to addSample. 

However, it would be a bit confusing if we want to separate adding to the total counter from adding to samples as well. Suppose we have a case that we want to keep both average and total, e.g., we want to see the average packet size for lwes events as well as the total network traffic emitted for lwes events. If we separate the two functionality, the users will have to make two separate calls, "increment("foo", time)" and then "addSample("foo", time)". Now the problem is if they called "increment("foo", time)" first, we would create a non-sample/timer type StatsMessage object for the key "foo" and then once they call "addSample("foo", time)", this won't be doing much simply because a non-sample/timer type StatsMessage does not have a list of samples in it. One solution would be to use a different name for samples, and another solution would be to not separate incrementing the counter and adding to samples functionalities. Another, more complicated, solution would be to use a separate map to keep the timer/sample type counters, which I am not sure if it is worth doing considering it is very likely that for majority of the cases we would want to keep both the total counter and the samples, and even if we don't really want to keep the total count, it is just a simple counter that is being incremented!