detect change in storage scheme and erase data as needed

[m-mcgowan]

The writeSlot method expects the first byte of data to never be zero. Under regular use, this is always the case.

However, when the address erase scheme is created on top of an area previously used by another scheme, and the application has not re-initialized the storage space, the flash will still contain data from the previous scheme, which is not valid for the address erase scheme.

The quick fix is to avoid the hang, so that the scheme behaves more robustly in the face of unexpected data. The tests TEST(MultiWriteSlotAccess, writeSlot_invalid_bitmap) and TEST(MultiWriteSlotAccess, readSlot_invalid_bitmap) have been created to express the problem and verify the fix. Prior to the fix, the code would hang.

As well as strengthening the code for unexpected data, the system should try to auto-detect when a region has been used for something else previously. This can be done by writing the configuration data to the housekeeping page. If this doesn't match the current configuration, then the system can automatically erase the area, since the data will not be valid.