chore: enhance custom error handling and documentation

[FlynnOConnell]

• Refactored CustomError to handle specific PostgreSQL error types, providing clearer error messages for database violations.
• Updated the IntoResponse implementation for CustomError to ensure appropriate HTTP status codes and error messages are returned in API responses.
• Added documentation for both the From<SqlxError> and IntoResponse trait implementations.

Errors to Handle

1. Users

• GET user -> Path(user_id) | 40X
  • if client sends an incorrect or unauthorized request
• CREATE user -> Json(credentials)
  • duplicate username -> sqlx::Error | 409 + Location header -> existing/conflicting resource?
  • password not strong enough -> not sqlx::Error | 403 Forbidden ?
• DELETE user -> Path(user_id) | 40X
  • user_id doesn't exist shouldn't ever happen
• UPDATE user -> Path(user_id)
  • Right now, empty first/last name and password work, may want to change this -> 40X
  • user_id doesn't exist shouldn't ever happen | 40X
• Signup and Login user should be a bigger separate issue

2. Channels

• All follow mostly the same logic as users for status codes and error handling

3. Messages

• In theory, Path(user_id), Path(channel_id) and Path(message_id) references shouldn't be an issue on our end | 40X

Tasks:

• [x] Better handle message references after user or channel deletion, Addresses #52

Still more work to be done on error handling. There are more cases to cover and potentially a better implementation. Consider a more robust approach as is done here for the future.

[FlynnOConnell]

Creating a user that already exists gives:

{
    "error": "Unique violation: duplicate key value violates unique constraint \"fluke_user_email_key\""
}

Creating a message with an invalid user_id gives:

{
    "error": "Foreign violation: insert or update on table \"message\" violates foreign key constraint \"fk_message_user_id\""
}

Though this shouldn't really happen. Many of the errors shouldn't happen but are logged anyway.

[FlynnOConnell]

add 404. We should also probably consider changing the name of the error to something better than CustomerError. Maybe FlukeApiError?

Added 404 and 401 UNAUTHORIZED for the future user authentication