[RFC] Resource.claim as an alternative to raise + access

[japaric]

With this PR, instead of writing this:

thr.raise(&R1, |thr| {
    let r1 = R1.access(prio, thr);
    // ..
});

You can write:

R1.claim(prio, thr, |r1, thr| {
    // ..
});

The latter form doesn't have the problem of over-raising the threshold (e.g. you
could have used R2 instead of R1 in the raise example shown above). The
latter form is also better for refactors. If you increase or decrease the
ceiling you don't have to change the R1.claim call. OTOH if you had code like
this:

fn foo(_: Exti0, ref prio: P1, ref thr: T1) {
    let r1 = R1.access(prio, thr);
}

and decided to change the ceiling of R1 to 2 then you would have had to change
the code to this:

fn foo(_: Exti0, ref prio: P1, ref thr: T1) {
    thr.raise(&R1, |thr| {
        let r1 = R1.access(prio, thr);
    });
}

The downside of exclusively using claim, which you have to do to get the
refactoring advantage, is the excessive rightward drift that comes from nesting
claim calls:

R1.claim(prio, thr, |r1, thr| {
    R2.claim(prio, thr, |r2, thr| {
        R3.claim(prio, thr, |r3, thr| {
            // ..
        });
    });
});

// vs
thr.raise(&R3, |thr| {
    let r1 = R1.access(prio, thr);
    let r2 = R2.access(prio, thr);
    let r3 = R3.access(prio, thr);
});

This could be addressed with a multiclaim macro (?) that lets you claim
several methods at once.

Another downside (?) of using claim is that it hides the fact that accessing a
resource may be creating a critical section. This makes it harder to visualize
the span of critical sections which makes it harder to estimate the blocking
time of a task (assuming you are not using tooling to analyze that).

The final downside is that, since this PR is adding claim instead of
deprecating raise and access in favor of it, we would end with two ways to
access resource (TIMTOWTDI). This means that we would have to document both
methods and list their advantages and disadvantages, and that we would be
placing the burden of making a choice on users.

cc @perlindgren

[japaric]

closing in favor of #31