rearrange some functions
introduce max_concurrent for load generators

By default, any load generator may have any number of ongoing
tasks. Typically this is not a problem as no load generator would have
more processes spawned than the intensity dictated by the load_spec. If
a task takes a considerable amount of time to complete, say, a second
the load generator naturally would have the intensity plus the tasks
that have not yet been completed running concurrently. The number of
total processes would still be rather constant.

This is working under the assumption that the run time of tasks does not
increase over time. In certain situations this can lead to a situation
where the runtime gets overloaded with processes and
terminates. max_concurrent introduces a way to cap the total number of
processes a load generator may have ongoing.

A special use case of this added feature is that the caller may
configure the load generator to operate in a synchrounous manner. This
would be equal to adding a load generators with max_concurrent set to 1.

- introduce max_concurrent for load_generators
- refactor the tick handling centralizing the decision making to one
  point
- introduce the CHANGELOG file
- add resources link to the README.md file
Merge pull request #8 in KC/ponos from introduce-max_concurrent-option to master

* commit 'a9acaf974e88bac4eeaa3ed22a9a3561a298c442':
  introduce max_concurrent for load generators
  rearrange some functions