Add support for uv init --script

[tfsingh]

This PR adds support for uv init --script, as defined in issue #7402 (started working on this before I saw jbvsmo's PR). Wanted to highlight a few decisions I made that differ from the existing PR:

1. --script takes a path, instead of a path/name. This potentially leads to a little ambiguity (I can certainly elaborate in the docs, lmk!), but strictly allowing uv init --script path/to/script.py felt a little more natural than allowing for uv init --script path/to --name script.py (which I also thought would prompt more questions for users, such as should the name include the .py extension?)
2. The request is processed immediately in the init method, sharing logic in resolving which python version to use with uv add --script. This made more sense to me — since scripts are meant to operate in isolation, they shouldn't consider the context of an encompassing package should one exist (I also think this decision makes the relative codepaths for scripts/packages easier to follow).
3. No readme — readme felt a little excessive for a script, but I can of course add it in!

@jbvsmo – hope it's okay I'm using the documentation you wrote!

[charliermarsh]

Thanks! Left some feedback, not far off though.

[tfsingh]

This is ready for another pass, thanks for the review!

[charliermarsh]

You generally want to avoid &PathBuf, similar to how you would avoid &String. The reasoning is similar to the previous comments around &Option<T> vs. Option<&T>. If you have a PathBuf, you can always get an &Path; but if you have a Path, you can't convert to &PathBuf without allocating.

[tfsingh]

I see, Path is to PathBuf what &str is to String clarifies this well, thanks!

[charliermarsh]

I refactored this to do a single I/O operation -- so, we try to read the script, and then we handle appropriate errors. It goes against the idea of using error handling for control flow somewhat, but it avoids race conditions are TOCTOU errors: in the previous implementation, between the time you checked the file metadata and the time you actually read the file, the file could be removed or replaced.

[tfsingh]

This makes sense — this operation felt a little like a "conversational" transaction of sorts, the new implementation is much cleaner

[charliermarsh]

Thanks @tfsingh! I also added @jbvsmo as a co-author.