This helper function is also useful to remind us that if we use
hrtimer_pull outside the scope of triggering remote releases, we need to
take care of properly set the "state" field of hrtimer_start_on_info
structure.

There is currently no need to implement this in ARM.
So let's make it optional instead.

Adapt to new schema for spinlock:
(tglx 20091217)
spinlock - the weakest one, which might sleep in RT
raw_spinlock - spinlock which always spins even on RT
arch_spinlock - the hardware level architecture dependent implementation

----

Most probably, all the spinlocks changed by this commit will be true
spinning lock (raw_spinlock) in PreemptRT (so hopefully we'll need few
changes when porting Litmmus to PreemptRT).

There are a couple of spinlock that the kernel still defines as
spinlock_t (therefore no changes reported in this commit) that might cause
us troubles:

- wait_queue_t lock is defined as spinlock_t; it is used in:
  * fmlp.c -- sem->wait.lock
  * sync.c -- ts_release.wait.lock

- rwlock_t used in fifo implementation in sched_trace.c
  * this need probably to be changed to something always spinning in RT
    at the expense of increased locking time.

----

This commit also fixes warnings and errors due to the need to include
slab.h when using kmalloc() and friends.

----

This commit does not compile.

Simple merge between master and 2.6.34 with conflicts resolved.

This commit does not compile, the following main problems are still
unresolved:

- spinlock -> raw_spinlock API changes
- kfifo API changes
- sched_class API changes

Conflicts:
	Makefile
	arch/x86/include/asm/hw_irq.h
	arch/x86/include/asm/unistd_32.h
	arch/x86/kernel/syscall_table_32.S
	include/linux/hrtimer.h
	kernel/sched.c
	kernel/sched_fair.c

hrtimers are properly rearmed during arm_release_timer() and no longer
after rescheduling (with the norqlock mechanism of 2008.3). This commit
accordingly updates the locations where measures are taken.

When a real-time task forks, then its LITMUS^RT-specific fields should be cleared,
because we don't want real-time tasks to spawn new real-time tasks that bypass
the plugin's admission control (if any).

This was broken in three ways:
1) kernel/fork.c did not erase all of tsk->rt_param, only the first few bytes due to
   a wrong size argument to memset().
2) It should have been calling litmus_fork() instead anyway.
3) litmus_fork() was _also_ not clearing all of tsk->rt_param, due to another size
   argument bug.

Interestingly, 1) and 2) can be traced back to the 2007->2008 port,
whereas 3) was added by Mitchell much later on (to dead code, no less).

I'm really surprised that this never blew up before.

GSN-EDF and friends rely on being called even if there is currently
no runnable real-time task on the runqueue for (at least) two reasons:
1) To initiate migrations. LITMUS^RT pull tasks for migrations; this requires
     plugins to be called even if no task is currently present.
2) To maintain invariants when jobs block.

- remove the call to litmus_tick() from scheduler_tick() just after
  having performed the class task_tick() and integrate
  litmus_tick() in task_tick_litmus()

- task_tick_litmus() is the handler for the litmus class task_tick()
  method. It is called in non-queued mode from scheduler_tick()