Option to specify how many ticks the simulation should run for

[czlee]

These commits add an option to the configuration file to specify how many ticks the simulation should run for. In order to facilitate the conversion of existing configuration files, it also adds to configuration the ability to specify an input file for modification, rather than generating all files from command-line options only.

These changes are (or at least we think they are) orthogonal to #30. These changes only provide for the maximum time a simulation can run time, and provide no provision for early bail-out. Taken together, the changes in #30 (I think) would then do its first run on 10% of whatever is specified in the config file. I can rebase them after #30 is merged if that would be desirable.

[czlee]

I just realized this will conflict with #34, which deprecates ConfigRange in favor of a new ConfigVector. I consider the extension of ConfigRange to be used for options in the evaluator other than network configurations a slight abuse of the class anyway, or at least something that turns ConfigRange into a misnomer.

As we start adding more options/parameters to the evaluator there should probably be a new class that encapsulates "a specification for what an evaluator is doing" and contains ConfigRange or ConfigVector anyway—sort of what ConfigRange does now, except that it covers more things. To provide another concrete example, if I'm adding the ability to specify when senders should start/stop sending, this would require another field in some EvaulatorParameters class (or similar) alongside ConfigRange/ConfigVector. For example:

message EvaluatorParameters {
    ConfigVector configs = 1;
    SenderPattern pattern = 2;
    uint32 simulation_ticks = 3;
    double log_ticks_interval = 4;
}

Thoughts? This would also give us a better framework to memorialize rat-runner configurations.