Supports dSTS by ClientApplication(..., authority="https://...example.com/dstsv2/...")

[rayluo]

Feature request #767 calls for support for dSTS authority.

The understanding was that:

• (a) The dSTS authority behaves similarly to an oidc_authority (i.e. no Instance Discovery, no "/v2.0" hardcoded string within its endpoint), so, it should just work if the caller would choose to put a dSTS url into the oidc_authority parameter, even if we might not advertise so.
• (b) Yet, we choose to allow using dSTS in the "traditional way", by accepting it via the authority parameter, so that MSAL's downstream ecosystem can support dSTS transparently without needing to pick up the oidc_authority parameter first.

Therefore, this PR attempts an implementation that simply converts the authority=https://foo.bar.example.com/dstsv2/placeholder into oidc_authority=https://foo.bar.example.com/dstsv2/placeholder under the hood, and then all the oidc authority behaviors will automatically kick in.

With regard to the tests:

• The test cases were refactored so that the new DstsAuthorityTestCase inherits all the previous OidcAuthorityTestCase (therefore testing point A above).
• A new test case was added to test the new behavior of authority=https://foo.bar.example.com/dstsv2/placeholder (therefore testing point B above)
• Currently, there is no new test cases mapping to the Acceptance Tests described in this request, because this PR builds up on top of the previously tested features (OIDC authority) and does not introduce new code in the token acquisition code path. In particular, #2 doesn't apply because MSAL Python does not support WithTenant(...). But I'm open to add more test cases if desirable.

This will resolve #767

P.S.: The test automation is currently failing due to other reason. They will be fixed soon outside of this PR. This situation does not prevent this PR from being reviewed. Test automation works again now.

[neha-bhargava]

Approve with comment to add another test for common as tenant