Add a --suffix option to uv tool install

[edgarrmondragon]

As mentioned in #3560 (comment), it'd be useful for uv tool install to have a --suffix similar to pipx's so users can install multiple versions of the same tool, or install a tool with different versions of Python.

[zanieb]

Extracting some of the context from the linked RFC:

Each entry point is added to the directory with its normal name, and name@<version>. This suffix allows tools with conflicting versions to be used across different scopes. The user may customize this suffix with a --suffix flag. If a custom suffix is provided, we will not include the plain name executable during installation.

When specifying suffixes, the @ is implied and will be included if the suffix begins with an alphanumeric character — if included by the user it will be trimmed for compatibility with pipx (which requires it to be included explicitly by the user). Leading characters such as - or _ will drop the implied @ allowing customization of suffixes. This behavior is not considered necessary for the initial implementation of this feature.

uv does not allow installation of multiple tools in the same scope with the same key. If installation of multiple versions of a tool is desired, a suffix must be used. If the user attempts to install another version of an already-installed tool, the existing tool will be replaced. If the existing tool installation contains dependency requests that are not requested in the invocation that would replace it, an error should be raised instead.

[zanieb]

The following is a bit confusing:

This suffix allows tools with conflicting versions to be used across different scopes

But we later say:

uv does not allow installation of multiple tools in the same scope with the same key. If installation of multiple versions of a tool is desired, a suffix must be used.

This is because the RFC talks about allowing installs at different scopes:

Tools can be installed into a user or system namespace, though the system namespace is more difficult to manage and should be considered a secondary objective during implementation.

We do not yet support system-level installs, so there's always one scope. We also do not currently add an alias for name@<version>.