Move towards the edm::Schedule creating all the processing streams
Use PreallocationConfiguration to declare all number of concurrent resources (e.g. Events) the job has been told to support. Propagate the information to all necessary parties. This is the first step to making the Schedule control those resources.
Separate construction of module from construction of Worker

WIth the threaded framework we need to share one module across multiple 'transitions'. Since we have one Worker per concurrent transition we need to separate the two.
This involves a new ModuleRegistry shared by multiple WorkerRegistries and having the ModuleRegistry now own the Modules instead of the Workers owning them. This
also required making maker::ModulerHolderT a friend of all the module types so it could access various setup functions which are private.
Added TriggerTimingReport and made sure all data used by TriggerReport is initialized

Each Stream will have its own partial summaries which will be combined using the
TriggerTimingReport and TriggerReport by the Schedule
EventProcessor and SubProcess just use a stream index

When referring to a Stream, the EventProcessor and SubProcess just
use an integer in order to allow easy iterating. The StreamID is used internally
by the Schedule and passed to the modules.
Separated internals of Schedule into GlobalSchedule and StreamSchedule

In order to accommodate multiple simultaneous Streams, the implementation of
Schedule has been broken into GlobalSchedule and StreamSchedule. The Schedule allows
for one StreamSchedule per Stream and at the moment only uses one GlobalSchedule.
The StreamSchedules and the GlobalSchedule share a ModuleRegistry in order to share module
instances.

The end job reports are a reduction of the summaries from all the StreamSchedules. The
GlobalSchedule does not participate since all of the information is Event based.

NOTE: This change is known not to pass all the unit tests.
Code cleanup

Removed unnecessary includes and source code.
Actually run Workers on transitions
Minor changes to include files
Properly handle reduction of top level ParameterSet

EndPaths which contain only EDAnalyzers and OutputModules are supposed to be removed
from the list of paths. The previous code only removed ones containing OutputModules. The
algorithm also required the contains to be sorted which was not done in the previous code.
This change also did some code cleanup.
Merge branch 'CMSSW_7_0_X' into multipleEventSupport

All changes which were made to Schedule in 'CMSSW_7_0_X'
have been moved to StreamSchedule.
Share on TriggerResultInserter between all Streams

Changed TriggerResultInserter into a edm::global::EDProducer which
is shared between Streams. The Schedule now owns the TriggerResultInserter.
Have unscheduled modules run first in global transitions

To match the old behavior of the system, I reordered the module
call sequence to have the unscheduled modules run first.
Commented out printouts to reduce clutter in unit tests
Change unit tests to expect the new order of operations

The TriggerResults is now constructed first and does not get
a Begin/EndJob signal. The TriggerResults also does not appear
in the Schedule's allModuleDescriptions output.
Unscheduled modules now are run first on Begin/EndJob
transitions which matches their order in Global transitions.
Cleaned up module and worker construction

Made separate files for ModuleRegistry and ModuleHolder. Cleaned up
arguments passed when creating modules and workers.
Merge branch 'CMSSW_7_0_X' of https://github.com/cms-sw/cmssw into multipleEventSupport

The commit 'Remove CurrentProcessingContext from CMSSW' conflicted with changes in Schedule.
I moved the necessary changes to StreamSchedule and GlobalSchedule which do the actual work.
Use generic OutputModuleCommunicatorT rather than specializations

edm::OutputModule and edm::one::OutputModuleBase used to have specialized
versions of OutputModuleCommunicator. These were easily replaced with a
templated class.
Removed include of FillProductRegistryTransients.h since file is gone
Give access to ModuleHolder's via a functor

Since the ModuleHolders now create the OutputModuleCommunicators
the system needed access to the holders. Using a functor avoids exposing
the fact that right now we are using a map to told the items.