Produce requirements.txt release artifacts

[devinrsmith]

It would be good to produce a set of requirements.txt release artifacts, with the knowledge that these requirements.txt files have all been through our unit and integration testing frameworks (and potential further QA).

It is likely that some matrix of requirements.txt would need to be produced. At a minimum, it would need to be per python version, and potentially as an addition, multiplied by each "extra" desired set of packages (all-ai, nltk, pytorch, etc..).

The downstream consumers of these files would be:

• https://github.com/deephaven/deephaven-server-docker
• End-user virtual environments (need to update best-practices documentation around installing virtual environments, https://deephaven.io/core/docs/how-to-guides/configuration/native-application/#python-environment)
• Python embedded server https://pypi.org/project/deephaven-server/
• DHE virtual environments

This is not a trivial task.

Firstly, we don't test a matrix of python versions at the moment - only 3.10. #3724

Secondly, we have a sort of cyclical dependency between https://github.com/deephaven/deephaven-server-docker and this repository. #3723

Related #3426

[devinrsmith]

As an additional upside, this might be a nice pattern for advanced integrators who want to specify their own requirements file and ensure all of the DHC unit / integration testing works.

[devinrsmith]

There may be architecture-specific flavors that need to be accounted for as well (amd64 v arm64).

[devinrsmith]

There may be value in publishing the docker/server-jetty/src/main/server-jetty/requirements.txt, even though it's a bit limited in scope (only tested on amd64, only python 3.10, etc...).

It's up for debate whether we want / need to strip out the "optional" dependencies from this list (related deephaven/deephaven-server-docker#71) such as turbodbc which needs to be purpose-built. That said, deephaven-server-docker as a downstream consumer does have the logic to build that wheel as necessary.