Maximum concurrent Jobruns

[linkdotnet]

Currently you can only define a recurring trigger which can't be executed in parallel (the second one will just be omitted).
This feature request should lift this to a more abstract level. Jobs itself should only be execute to a specific amount. This could come in handy when a job is very resource-intensiv and or long running.

If you trigger a job via an instant trigger which is long running and resource intensiv and the job is described with only one concurrent JobRun, the next Run should be scheduled and should wait until the first is finished.

[linkdotnet]

Based on the discussion with @michaelschnyder the following outcome was proposed:
Jobbr.Server
The Job-Definition will get a new flag MaximumConcurrentJobRuns, which indicated how many JobRuns of one Job can run in parallel.
To achieve this the PublishCurrentPlan in the DefaultScheduler is extended so that it will check for this condition. This method is the central point for creating PlannedJobRuns.
As a consequence the version from the Jobbr.Server is bumped from release/1.5.0 to release/1.6.0. Backwards compatibility is achieved via a default value of 0. 0 means unlimited JobRuns can run in parallel.

Furthermore the Jobbr.ComponentModel.JobStorage has to be extended with this specific property.
This also means a version bump from release/1.0.1 to release/1.1.
Last but not least MsSql.StorageProvider has to be extended, because the new property has to be persisted.

@olibanjoli In Version 1 of the MsSql:StorageProvider DbUp was used for migrating the database. This support dropped out of version 2. What was the reason behind this decision? Do you think it would be useful to integrate it again?
Because a new column can lead to a failing ORM. We have to implement a fallback value, if this column is not present. If so, we can make a minor version bump, otherwise a major release is needed due the breaking API-changes.

[linkdotnet]

Related PR: #66