Distinguish an invalid API key from connection errors #1

Hi there!

I'm interested in getting the EmonCMS HA integration bumped up on the quality-scale a bit. To do so, I'd like to add a re-authentication flow (a Silver quality-scale rule). That needs the integration to recognize an invalid API key, but EmoncmsClient currently reports it the same way as any other failure.

What happens today

With an invalid key, Emoncms answers every endpoint I tried (feed/list.json, feed/aget.json, user/getuuid.json) with HTTP 401 and the plain-text body Invalid API key.

In the current v0.1.3, async_request() turns that into the dict:
{"success": False, "message": "error 401 unauthorized access"}

A timeout or connection failure comes back the same way, only with a different message string. So the only way to tell them apart is to parse the message rather than the current HA guidance to raising exceptions.

async_get_uuid() returns None on a 401, the same as for a server too old to have a UUID. In Home Assistant, that means a bad key raises the "upgrade your Emoncms database" repair issue, which sends the user to the wrong fix.

What do do?

Raise distinct exceptions from async_request(), for example:

class EmoncmsError(Exception): ...
class EmoncmsAuthError(EmoncmsError): ...        # HTTP 401
class EmoncmsConnectionError(EmoncmsError): ...  # ClientError, timeout

We could either have this be an explicit opt-in from the Home Assistant side (raise_errors=True in the EmoncmsClient call) or drop the HTTP response as a new prop in the dict the library already returns. I prefer the opt-in approach, as that's a cleaner interaction that seems to be what HA wants these days, but can adjust to your preferred approach.

Let me know your thoughts. I'm happy to open a PR to get this in motion!