Problem:
When multiple scheduling events occur simultaneously, a situation could
happen where:
- one core schedules a task that is linked to it
- a check_for_preemption occurs due to another scheduling event
- that task is now linked to another core
- the other core tries to schedule it but can't grab the task from the
  runqueue of the other core

Solution:
Added in the scheduled_on field in gedf_reservation. This enables us in
link_task_to_cpu to check for this occuring and swap the linking so the
above situation doesn't happen. The code is taken and modified from
link_task_to_cpu in GSN-EDF

Added a system call for the lock holder to check if it is
in a forbidden zone and if so, suspend until the beginning
of the next time slice for its parent component.

This does not include any "skipping ahead" mechanism.

This includes priority inheritance, but no concept of
forbidden zones.

This is the variant of the OMLP that uses priority inheritance,
and comes from BBB's dissertation work.

Reduces the size of our diff from upstream litmus and
should have no impact on functionality. Ported from MC^2.

Dynamic CPU entry/exit changes:
- Fix build with CONFIG_RELEASE_MASTER
- Migrate gedf_env release timer when a core is suspended
- Fix race condition in gedf_env core resume
- Add documentation
- Allow for gedf_env_suspend() and gedf_env_resume() to be called
  on CPUs that have already been suspended or resumed. (They do
  nothing in those cases.)
Portability:
- Allocate space in `gedf_reservation_environment` using
  `num_online_cpus()` rather than `NR_CPUS`. Otherwise the stack
  frame can overflow when `NR_CPUS` is large.
- Assign `plugin_state` from the plugin rather than the extended
  reservations code to support other uses of `plugin_state`.
Misc:
- Improve robustnesss of `gedf_env_is_np()`
- Don't memset with 0 memory already zeroed-out by `kzalloc()`
- Use GFP_ATOMIC for allocations when in a scheduling context

Bugs fixed:
- cpu priority comparison in gedf environment made it so cpus were
ordered opposite to what they are supposed to
- shutdown of component did not free all memory

Note: It is up to the table maker such that components do not cause
cross migrations of tasks

Fixed the following:
-reservations(both mtd and gedf) were not properly added to the all_reservations list that
allows it to be found by find_res_by_id
-mtd_reservations not linked after it has been allocated
-fixed mtd_env_dispatch logic so that when nothing is in ready_queue, it
scheduled NULL instead of currently scheduled reservation
-fixed find_res_by_id forgetting to release lock