Add additional frontend validation and/or error messages on the New Release page

Problem to solve

When creating a new release using the New Release page (implemented in #214244 (closed)), it is possible to fill out the form without validation errors in the UI, but receive a generic error message when the Create release button is clicked due to backend validation.

For example, here is what the page looks like if a user tries to create a new release with an invalid tag name:

The same generic error message - "Something went wrong while creating a new release" - is shown for all errors: validation errors, bugs, or outages. Because of this, it's not clear to the user what caused this error or how to proceed.

Intended users

Anyone who creates releases using the New Release page.

User experience goal

It should be clear to the user when they enter invalid information and how they can fix it.

Proposal

We should:

1. Add frontend validation that lines up with the existing backend validation, or
2. Update the backend to send a validation "code" of some sort that the frontend can use to display a more specific error message (e.g. "Invalid tag name").

(Or perhaps some combination of these two.)

Further details

Below is the current state of validation on the New Release page. Any validations that are only implemented by the backend runs the risk of the user getting the generic "Something went wrong" error message.

Validation	Implemented by backend?	Implemented by frontend?	Notes
Tag name must be provided	✅	✅	The frontend considers all-whitespace names invalid
Tag name must be in the correct format	✅	✅	For example, a tag name like "invalid tag name"
The tag does not already exist	✅	✅	Interestingly, if the user first creates a tag on the New Tag page, they can use the New Release form to create a release based on this tag by re-entering the tag name in the Create from field. This isn't an intentional behavior; rather, it's a side effect of the way the Releases API is designed.
Tag is not already associated with another release	✅	❌	For example, if the users enters the name of an existing tag that is already associated with a different release
Asset link URL must not be empty	✅	✅
Asset link URL must start with http://, https://, ftp://	✅	✅
Asset link URL must be a valid URL	✅	❌	For example, the frontend accepts a URL like https://, but the backend rejects this
Milestones are valid	✅	✅	The frontend doesn't "validate" this per se, but it does so indirectly by only allowing the user to select valid milestones
Tag is protected	✅	❌	See comment below.

Any new validations could (and probably should) be implemented in separate MRs and released separately.

Documentation

This change would require no additional documentation.