Refactor directive ids in scheduler

[JoelCourtney]

My understanding of the current use of directive IDs in the scheduler is this:

• The database acts as the source of truth for what the directive IDs "actually" are.
• In the scheduler, existing directive IDs are negated, while newly created activities use positive IDs.
• The scheduler also reindexes IDs entirely when calling simulation, using a counter in SimulationFacadeUtils.
• The scheduler performs one last map when uploading new activities to the database, allowing the database to decide the final ID in case new activities were added independently during scheduling.

This doesn't include any mapping between directive and instance IDs. All of these steps are mapping directive IDs around, and I believe the middle two are unnecessary and can be removed. Essentially we should always be consistent with the database when possible; it is only impossible for activities that aren't uploaded yet, and we should regain consistency as soon as they are inserted.

I will give the priority solver an autoincrementing ID cell that it can use to assign new IDs, starting 1 above the highest ID already in the plan. Since the cell will be unique per scheduling run, we won't get any collisions.

• I will probably delete the SchedulingActivityDirectiveId class in favor of just using ActivityDirectiveId.
• I will delete all of the directive-to-directive ID maps except for any in the upload step. This will impact SchedulingActivityDirective, SimulationData, PrioritySolver, SimulationFacade.PlanSimCorrespondence, SimulationFacadeUtils and SynchronousSchedulerAgent. The plan-sim-correspondence part of CheckpointSimulationFacade should be a bit simpler but still needs to exist to help searching for cached sim engines.