Scheduler & Semaphore fixes

This includes the following changes:

- The AP_HAL Scheduler has three new methods

```
bool in_timerprocess();
bool system_initializing();
void system_initialized();
```

These have been implemented for the AP_HAL_AVR, AP_HAL_Empty, AP_HAL_AVR_SITL, and AP_HAL_SMACCM schedulers. (So, everything but PX4.)

`in_timerprocess` tells a program the context it is being run from, so it may
take a semaphore in the correct way, i.e. nonblocking and fail gracefully if in
timerprocess, blocking and fail with panic if in main thread.

`system_initializing` tells a program whether the system is still inside
`setup()`, versus `loop()`. An asynchronous process may want to handle
nonblocking semaphore failures in a different way depending on whether the
system is still booting up or not - during boot, another device may hold the
semaphore from the main thread for a long time.

`system_initialized` is set by your AP_HAL_MAIN after `setup()` is complete. It
should only be called once.

The MPU6000 driver has been transformed to use in_timerprocess to handle
semaphores correctly.

The MS5611 driver and Compass driver have been transformed to use the
`system_initializing` check, and not panic on async semaphore gets if the
system is initializing. This will only affect the SMACCMPilot platform, which
is the only place where MS5611 and compass share the same (I2C) semaphore.