Allow EventPrincipal to create its own StreamID
Can now create its own StreamID so just pass the index to the constructor
PrincipalCache now supports multiple concurrent EventPrincipals
Do not update EventSetup on event transitions
Processes a contiguous group of events in an inner loop

To support concurrent event processing, we need to isolate the
event handling from the rest of the transition handling. This is the
first step.
Moved continuous loop over events into method called from state machine

Since the state machine makes certain useful guarantees when doing an Event transition,
I moved the contiguous event loop into the method called by the state machine when an
event in encountered. This will later change to be where the different Stream tasks are launched.
Percolated PreallocationConfiguration down to WorkerParams

Stream modules and modules which have Run, Lumi or Stream caches
needs to know how many 'slots' to reserve. This gets the information down
to where modules are constructed.
Properly preallocate all per module per stream items

Percolated the PreallocationConfiguration into the module base classes and passed the number of streams to the appropriate virtual functions which are overwritten in the appropriate inheriting classes. The per Run and LuminosityBlock items are still just single items since having multiple such transitions is a later phase of the project.
Allow more than one stream in the job

If more than one stream is requested in the configuration, create them and then distribute the events using a round-robin algorithm.
Updated SecondaryEventProvider to use the new constructor for WorkerManager
Merge branch 'CMSSW_7_0_X' containing pull request #681 into multipleStreamsInEventProcessor

Resolved minor overlapping change in EventProcessor.cc and SubProcess.cc. In both cases the
resolution was to use the change already in this branch.
Merge pull request #685 from Dr15Jones/multipleStreamsInEventProcessor

Multiple streams in cmsRun