Unable to use arbitrary uuid versions with Ash.Type.UUID

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

### AI Policy

- [x] I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

### Versions

Due to the change in #2373 which added strict `cast_input` for both Ash.Type.UUID and Ash.Type.UUIDv7, it is no longer possible to use arbitrary binary content for UUIDs.

#2373 allows only uuids with a version byte of 1..5 or 7 to be used with Ash.Type.UUID, and prevents anything but version 7 UUIDs from being used with Ash.Type.UUIDv7.

If a user wants to remove this restriction, they may, in each of their projects, instead provide their own copy of Ash.Type.UUID with the cast_input modified to match that capabilities of the underlying datastore (which as far as I can tell always allow any UUID-type data without trying to validate versions).

Validation like this was previously added and reverted in Ecto. https://github.com/elixir-ecto/ecto/issues/2147#issuecomment-321381804 has a description of why Ecto decided it was wrong for them to attempt to validate UUIDs. Not all the logic there applies completely to Ash, but some of it does.

Given how these Ash.Type.* are used, it makes sense to make separate types that add these stricter validations for those that want them, but continue to support a base-case UUID type.

This issue made upgrading a project I work on from an older version of Ash more complicated than it could have been.

### Operating system

MacOS

### Current Behavior

UUIDs with unrecognized versions raise exceptions:

```
Unknown Error
* ** (ArgumentError) cannot load `<< ... >>` as type #Ash.Type.UUID.EctoType<[]> for field :xxx in %A.B.C{xxx: nil}
```

### Reproduction

Create a Ash.Type.UUID attribute in a resource. Use a version that doesn't match 1..5 or 7.

### Expected Behavior

Accept the UUID instead of checking the version.

Review the cast_input behavior in Ash.Type.UUID and Ash.Type.UUIDv7, then compare it with the change described in #2373 and the Ecto discussion linked in the issue. Reproduce the failure with a UUID whose version is outside the accepted set; done means the base UUID type accepts it without a version-validation exception.

Written by the indexing model from the issue text.