Backend: Enforce use of semantic versioning for catalog resources

Problem

The use of ~latest version qualifier for CI components is not guaranteed to return the latest semantic version of the component. For example:

1. Create and release a tag v2.0.0
2. Then, create and release a new tag v1.5.0
3. the ~latest version returned will be v1.5.0 because under the hood we use released_at field.

Challenges

The Release model that powers the creation of new versions of catalog resources does not have knowledge of semantic versioning. It's possible to create releases as one, two, three and the system not being able to understand that.

Proposal (Updated)

• When a new version is created enforce the use of semantic versioning in the tag . Fail with an error on version creation if the tag does not follow the semantic versioning
• Update the default sort in VersionsFinder to be semantic_version_asc (name tbc)
• Update the order_by method in Ci::Catalog::Resources::Version to default to semantic_version_asc
• Ensure that ~latest version qualifier for CI/CD Components and skip versions marked as beta/rc/alpha .

Opportunities (out of scope for this issue and epic)

Semantic version enforcement could be a feature we could move downstream to Release feature by allowing maintainers to enable a project settings. This means that maintainers can enforce the use of semantic versions for releases outside of catalog resources.