Rework exception macro expansion for faults

[tropicaaal]

Closes #221. This also prevents marking #[entry]s as async, since that's a no-op (I guess that's technically a breaking change, so I can revert that if needed).

example:

#[exception(DataAbort)]
fn data_abort_handler() -> ! {
    loop {}
}

// now roughly expands to...

#[doc(hidden)]
#[export_name = "_data_abort_handler"]
pub unsafe extern "C" fn __aarch32_rt_data_abort_handler (_addr : usize) -> ! {
    fn data_abort_handler () -> ! { loop { } }

    // If `data_abort_handler` had one or more params, the macro would try to pass it `_addr`.
    data_abort_handler()
}

This is a draft because there are still some other potential edge cases and things i'm not sure of, notably:

• Is the intention of attributes on exceptions for them to go on the outer function or the inner function? (right now it does both, which is probably (?) bad, but changing that behavior would also be maybe breaking since Exception::SupervisorCall has always done that). If it's the latter only, is check_attr_whitelist still necessary?
• Should we do additional validation on the inner function's signature like #[entry] does for clearer user errors, e.g. if the user tried to mark their IRQ handler as async or something?
• Should we validate the argument type validation for addr in the macro? This should now fail after expansion because the macro will attempt to pass the inner function a usize, but we could catch it earlier if we wanted.
• unit tests maybe?

[jonathanpallant]

This is a tricky one. The cortex-m-rt crate has the same issues, so I'm going to bring this to a future Embedded Devices Working Group weekly meeting to see if we can hash out the "best" way to allow user-specified handler functions like this.