Fix bug in reset that wasn't setting status properly

[chrisbailey4]

Removed setting the _status_last to the return value as the return result isn't just the status field.
The _transceive function is actually setting the _status_last as part of the function so there is no need to do anything additional in reset

This addresses Issue: #25

[caternuson]

Looks good and agree it seems like an unnecessary, and potentially incorrect, setting of status.

Did you test this code with the original issue to make sure it fixed things there? Seems like this bug could be demonstrated by simply calling display_status after a call to reset?

[chrisbailey4]

Hi @caternuson I did test the code with the original issue and confirmed it addressed my issue.

The Bug is slightly more complex then just calling display_status after reset... In my specific case, I was attempting to enable the burst mode on the chip and I managed to get the chip into a state where it would properly respond to the self._transceive(bytes([_CMD_RT])) call in the reset function. However I would get an exception, IO error, during the self.magnetic call. In a normal reset call the self._status_last is properly set in the magnetic call, so the fact that it wasn't set in the call above would hardly ever been experienced.

This truly is a minor case that I hope not many people experience, but for those that do I am happy to provide this fix to save them 30 minutes of debugging :-)

[caternuson]

Gotcha. Yep, that makes sense. That sneaky call to magnetic was normally masking the issue. Subtle little bug. Thanks for discovering and fixing this.