Consider making stand-alone installation easier on Linux & Windows

[lread]

Is your feature request related to a problem? Please describe.
While reviewing the poly install docs, I noticed there can be quite a few manual steps for stand-alone installation for Linux and Windows. This might be overwhelming to a newcomer.

Describe the solution you'd like
On other projects, I've seen the use of install scripts.

For examples:

• deps.clj has an install script for macOS/Linux and an install.ps1 for Windows.
• clj-kondo does something similar (although it uses scoop for Windows).
• babashka recommends brew for both macos/Linux.

For all the above, manual download is also an option.

Another benefit of an install script is that it can also do a checksum on anything it downloads.

Describe alternatives you've considered
Consider describing brew as an option for Linux.
Consider creating something on scoop for Windows.

Additional context
Poly stand-alone has 2 assets: the jar and the launcher script.
The launcher scripts could be generated by the installer and/or made available for manual download from a set of release assets.

If I remember correctly, the lein script will actually download any necessary assets, so that might another place to look for inspiration.

[lread]

Additional note: While reviewing the upgrade docs, I think that whatever solution covers poly installation should also consider poly upgrade.

[seancorfield]

If you need to work with additional tooling, such as 3rd party test runners (my external one or the Kaocha one), you need to be able to control the classpath so it is already hard to use the standalone tool with them.

I'd be inclined to deprecate the standalone tool. You can add a :poly alias to your user-level dot-clojure deps.edn to get a system-wide "install" and that's already idiomatic for dev tooling, and in most cases any given Polylith project will have a :poly alias for a specific version of Polylith that should be used with that project anyway so the standalone tool only really makes sense for the initial create workspace command... and a user-level :poly alias seems the way to go.

That simplifies the build/test process for Polylith and streamlines the documentation, and provides a "standard" way to make Polylith available to a user for "all projects", or at least for creating new projects.