Consider supporting additional dependency formats

We use bot RSConnect and pypoetry quite a bit. It would be great if rsconnect-python supported deploying pypoetry projects or other ways of plugging in to pyproject.toml buiold systems.

We currently work around this limitation by wrapping rsconnect with our own tool that first runs poetry export (without extra repo urls) and copies our apps (stored using an src project layout) to a deploy directory containing the AppStore json file. We use the fact that rsconnect.environment stops after finding a requirements.txt.

There's multiple aspects of this request:

Implementation options
1.1 Possibly consider supporting poetry directly
1.2 There are other competing approaches to python dependencies e.g. PEP 631 allows dependencies in the pyproject.toml and other package management tools like Hatch use that. Allow cli callers to specify a cli tool to be called for resolving project dependencies
1.3 like 1.2 but only expose it via an api (i.e. pluggable build / dependency systems would only be supported by writing a custom tool that has rsconnect-python as a dependency and invokes it programatically.

Streamline non-pypi package registries
When running poetry export on a project that's setup to use non pypi repositories, extra pip urls are included at the top of the generated requirements.txt. When the repo is private and password protected

1. rsconnect-python fails to properly parse the requirements
2. the username and password are included in the file, which is insecure given how connect deploys content.
   We currently work around this by stripping any extra pip url lines and manually configuring the connect serve's pipconf with the required private package registry details.

Support other project layouts
We organize all our project sources under a src folder. Poetry already knows about our python path and where our sources, tests and resources live. One possible approach would be to allow deploying an app by copying dist tarball since poetry build can easily produce that (the poetry.lock / poetry export should still be used to resolve dependencies though).

Start with the issue's described rsconnect.environment handling of requirements.txt, then reproduce the poetry export workflow and private registry case. Compare the requested pyproject.toml dependency resolution, src layouts, and dist tarball deployment options. Done would require a decided scope and implementation path covering the selected dependency and project-layout behavior.