P-FP: avoid panic in PCP unlock() if lock owner exits

The current BUG_ON() is too strict if a task exits (or ceases to be RT
task while holding a lock). Weaken the assertion to allow this corner
case.
P-FP: document that PCP and DPCP do not handle remote unlock

It is currently not possible to unlock a PCP or DPCP from the "wrong"
core.  In normal operation, this never happens. In a rare corner case,
however, it is conceivable to occur if the following sequence of
events occur:

1) {D}PCP lock()
2) task transitions to background mode
3) task migrates to different core as a best-effort task
4) {D}PCP unlock() <- remote unlock attempt

Fixing this is a bit tricky. For now, let's at least document the
shortcoming and avoid failing silently by adding a corresponding
assertion.
P-FP: avoid assertion failure in DPCP unlock() if task exits

pfp_migrate_to() works only correctly for real-time tasks. For
non-real-time tasks, it has no effect. Weaken the assertions to
accomodate exiting tasks that still hold a DPCP lock.
PSN-EDF: avoid panic if FMLP lock-holding task exits

The invariant in unboost_priority() is too strong if a task exits.
Weaken the invariant accordingly, matching the previous patch for the
P-FP plugin.