Improve server function client side error handling

[drdo]

Handle all error codes 401-499 in addition to the 400 and 500-599 that were already handled.

In addition, handle them all in the same way and improve the error message.

The idea came about when trying to handle authentication in an axum layer
by setting the 401 status code.
In this situation the client side still tried to parse the body as if this was a
success case and failed with a deserialization error message.

[gbj]

Hm okay so the only complication I can see, and which would be a breaking change relative to the status quo, is this:

// semi-pseudo-code because I'm being lazy
#[server] 
pub async fn am_teapot() -> Result<String, ServerFnError> {
  let resp = expect_context::<ResponseOptions>();
  resp.set_status(418);
  Ok("I'm a little teapot".to_string())
}

The server function is returning Ok("I'm a little teapot"), but the client deserializes it as Err(ServerFnError::ServerError("418 IM A TEAPOT: I'm a little teapot.") or something.

i.e., it's possible for a user to manually set a 4xx response and also return a valid Ok condition from a server function. I'm open to opinions on how to handle this.

[drdo]

In my opinion I wouldn't even try to parse JSON at all on the client if the HTTP response is 4xx or 5xx.
These are error codes and I don't see the upside to using them for successful requests.
I simply left that in to keep the same behaviour that was already happening in the 5xx case.

I like the idea of the server being able to provide a more descriptive error string though.

[gbj]

Make sense. This looks good to me.