prepare utils for pypi distribution

[leahecole]

Description

I redid the setup.py with a better, more descriptive name, and added a pyproject.toml. I haven't added it to PyPI yet in case we wanted to do something like change the name, but to test locally, you can

• Change to this branch and to composer/dag_test_utils
• Build with python3 -m build (you might have to pip install build)
• Change to ../workflows
• pip install ../dag_test_utils/dist/cloud_composer_dag_test_utils-0.0.1.tar.gz
• Open a python editor and try import internal_unit_testing - you may see some deprecation warnings, and those are okay. They're part of underlying Airflow and will be resolved in the next release. If you see any ModuleNotFoundError errors, we should talk because I probably got something wrong.
• (alternative path) go to the requirements-test.txt and replace the gross URL with ../dag_test_utils/dist/cloud_composer_dag_test_utils-0.0.1.tar.gz, then run nox -s py-3.8 -- quickstart_test.py (or any of the tests, or the whole test suite - I just suggest doing one for speed reasons because the pip install of Airflow is slow)

I have requested a pywindows cloudtop and will test these distributions on windows and linux as well, and I have properly registered a team account on PyPI for the Cloud Composer DPEs per the OSPO instructions.

Preview of Coming Attractions
Once this is merged, I'll

• Make a small PR to requirements-test.txt files under Composer so that it pulls this package not a gross URL
• Make a PR with a major version update that upgrades this code to Airflow 2.0
• Point PR cleanup: Upgrade Composer samples to Airflow 2.0 #5782 to that new major version upgrade

Note: It's a good idea to open an issue first for discussion.

Checklist

• I have followed Sample Guidelines from AUTHORING_GUIDE.MD
• README is updated to include all relevant information
• Tests pass: nox -s py-3.6 (see Test Environment Setup)
• Lint pass: nox -s lint (see Test Environment Setup)
• These samples need a new API enabled in testing projects to pass (let us know which ones)
• These samples need a new/updated env vars in testing projects set to pass (let us know which ones)
• Please merge this PR for me once it is approved.
• This sample adds a new sample directory, and I updated the CODEOWNERS file with the codeowners for this sample

[crwilcox]

should google be in the package name or is this agnostic to our stuffs?

[leahecole]

At the moment, it's agnostic to our stuff, though I could envision it being expanded to be more composer-y in the future. I wasn't sure if there were restrictions on using google in the package name - I'm happy to add it if you think it's appropriate here

[crwilcox]

I could go either way on this. I tend to think being upfront that "this is a google package" is an alright thing, but could also think that by not including google in the name it is more likely to be 'hidden' when folks search for things. :)

[leahecole]

Okay! I think I'll keep it as is for now for that 'hidden' reason