Memory Commands

`0x0A - 0x1F` are free bits in the customer memory map that can be used to store various information, e.g. a serial number, location, etc.

Currently the code only uses the `RR` and `WR` commands to effect the volatile memory on the chip. The `HR` and `HS` commands which effect the non-volatile memory are not implemented. This makes those bits sort of useless since they aren't retained between power cycles/resets.

The `HS` command would be (mostly) trivial to add, but adding the `HR` command could potentially cause issues as most of the existing properties for the sensor class don't actually read the registers, instead relying on them being updated when the setter is called.

Hoping to get some consensus on what the best way to proceed regarding adding the `HS` command and what to do about the `HR` command:

1. Leave `HR` unimplemented – this is always performed on power-up or after the `RT` command anyway
2. Implement `HR` but rely on the user updating any modified properties
3. After doing an `HR` command update all the properties inside that function
4. Change all the properties to actually read their registers rather than just returning the internal value

Some comments about the different options:

1. Leaves all the current issues as-is (right now if you do a reset command after initialization any data reads could potentially be incorrect if you changed gain/resolution/etc) but still allows users to use the free memory
2. Implements all the commands but would require the user to either reinitialize or set any changed parameters (this seems the most common among the few libraries that implement the command)
3. Is kind of a half-measure and leaves most of the existing code alone
4. Would make sure the properties were always current but is the biggest code change

The most robust solution would probably be to update all the properties after the `RT` and `HR` commands to make sure the internal ones match what the chip actually has. I suspect no one has run into issues with the reset function since it's normally only used during initialization where all the properties are set immediately after being called anyway.

I'm partial to going with 2 since it involves the least amount of code change and anyone using the memory functions is probably an advanced user anyway. There should probably be a note to not call the reset function outside of initialization though.

Start by reading the sensor class's existing RR and WR command handling, then trace how its properties store values instead of reading registers. Resolve which HR and HS behavior is wanted before changing code, especially how HR should synchronize properties after resets. Done means the agreed memory commands work across power cycles without leaving documented property values inconsistent.

Written by the indexing model from the issue text.