Add documentation for external pypi

[akaszynski]

This PR adds documentation detailing the usage of our external PyPI. I think these docs should be public for the following reasons:

1. Keep with single source documentation.
2. Our CI (private and public) at some point will expose this in a workflow file. Therefore, not documenting this will merely help with "security through obscurity", which isn't security. True security will be protecting (and rotating) the PAT and not allowing forked repositories to have access to tokens (which they don't).

[ansutremel]

@akaszynski what are other companies doing which might have similar scenarios?

[akaszynski]

Desire

There is a huge push for packages to be hosted in GitHub packages, and I think the drive is to do that:
https://github.saobby.my.eu.orgmunity/t/pypi-compatible-github-package-registry/14615/103

Solutions I've seen in the wild

A common solution has been to use public ADO for hosting both universal artifacts and Python packages. Another alternative within GitHub is to use a repository for that:
https://github.com/astariul/github-hosted-pypi

While this solution works, it's non-optimal as you have to git push and we would still have to track a PAT as pulling would require access to a private repository.

Other alternatives include

• Using the GitLab PyPI repository (we don't use GitLab).
• Hosting Private PyPI Server on Kubernetes (we don't want to maintain our own PyPI server.

In the end we chose ADO to:

• Avoid the security risk external pulling from internal, having to create a new internal registry.
• Avoid creating our own private PyPI registry thereby opening up a new attack surface.
• Reuse a tried and true Microsoft backed service.