Update error handling

[Derpthemeus]

As brought up in some PR comments and Slack discussions, it may be a good idea to review how we're handling errors. Some changes I suggest include:

• Any method that currently returns/resolves undefined to indicate failure should instead throw/reject errors. This would align with standard error handling paradigms and would allow us to include more information about each error.
• We should log any unexpected errors (i.e. not caused by missing optional fields in API responses) so we can find and fix them faster.

We may also want to change how the server sends errors to the OS firmware, but these changes may be backwards incompatible.

• We should be more transparent about errors when sending information to the OS firmware. Instead of setting the watering scale to 100% server-side, we should indicate that the scale could not be calculated and let the firmware select a default (either using the previously calculated watering scale or 100%).
• We should use the appropriate HTTP status codes to indicate if a request was successful, errored due to a server issue, or errored due to an issue that the user must correct.