Add Security Attribution Unit support

[hug-dev]

The SAU is a Armv8-M core peripheral that, alongside the Implementation
Defined Attribution Unit, manages the security attribution of the memory
zones.
This driver provides abstraction to help setting the SAU up.

This pull-request adds a new dependency, bitfield which provides a really nice way to describe bit fields in registers with methods to access them. It makes it really easier to use/write rather than having to manually declare the shift number and mask constants.
Although bitfield does not have any dependency, I am well aware of the increased cost of memory its addition could cause to embedded targets.
I am really open to criticism about its use, if you would prefer me not to use it, or if you would like to see benchmarks of memory usage for some reference targets of embedded Rust 😃

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ithinuel (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[thejpster]

bitfield ... provides a really nice way to describe bit fields in registers

I think the medium-term plan was to find/write an SVD file for the Cortex-M core peripherals, so we could use svd2rust and generate a cortex-m-pac (which this high-level crate would then use). But I think this is a good interim step.

[japaric]

This is a breaking change. Adding a field to a structure that only has public fields is a breaking change.

"Why?" Because of destructuring syntax:

fn foo(a: A) {
    let A { b, c } = a;
}

struct A {
    pub b: u8,
    pub c: u16,
    // pub d: u32, // adding this breaks the above `let` statement
}

[hug-dev]

Maybe it is better to wait that the cortex-m-pac crate is available to remove the bitfields dependency and use that.

[hug-dev]

Assuming that #193 is merged I guess this would not be a breaking change anymore and hence be merged more easily?
It could use the bitfield crate for now and I can switch to using the cortex-m-pac crate in a future PR when it is available.

[thejpster]

Let's get this in. We can reduce the impact of any breaking changes subsequently if we want to.

[thejpster]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push