Simplify experience when using endpoint-based connection: leverage `DefaultAzureCredential` by default

The `Connect(Uri, TokenCredential)` API forces the consumer to always specify a token credential, which to me seems fairly unnecessary considering we have a very sane default called the `DefaultAzureCredential` class.

I propose one (or 2) of the following:

1. Create a new overload to `IConfiguraitonBuilder.AddAzureAppConfiguration` that takes _just_ a `Uri` object, and uses `new DefaultAzureCredential` behind the scenes.
2. Modify the existing `AzureAppConfigurationOptions.Connect(Uri, TokenCredential)` method to make the `tokenCredential` argument optional: if it is not specified, default to `new DefaultAzureCredential`
3. [Alternative to 2 if default arguments are to be avoided] Create a new overload for `AzureAppConfigurationOptions.Connect(Uri, TokenCredential)` that takes only the `Uri` argument and defaults the credential internally to `new DefaultAzureCredential`

I believe this would significantly streamline configuration, especially when you connect to multiple instances like we do. This is currently our implementation for context:
```csharp
builder.Configuration
.AddAzureAppConfiguration(c =>
c.Connect(
endpoint: builder.Configuration.GetValue("Azure:AppConfiguration:Common:Endpoint"),
credential: new DefaultAzureCredential()))
.AddAzureAppConfiguration(c =>
c.Connect(
endpoint: builder.Configuration.GetValue("Azure:AppConfiguration:Endpoint"),
credential: new DefaultAzureCredential()));
```

And this is how it would look like with option 1 above:
```csharp
builder.Configuration
.AddAzureAppConfiguration(builder.Configuration.GetValue("Azure:AppConfiguration:Common:Endpoint")
.AddAzureAppConfiguration(builder.Configuration.GetValue("Azure:AppConfiguration:Endpoint");
```

PS: The reason we fetch the endpoint from configuration itself is because we have dedicated instances of Azure AppConfig for each of our environments.

I'm aware this would add a new dependency to `Azure.Identity` on the package (since every single implementation of `TokenCredential` comes from there) but to me that seems fully justifiable and I'd even make the argument that it would simplify this interaction even more to the consumer as he doesn't need to be aware of a separate package that needs to be introduced to even be able to call these endpoint-based overloads.

If the team is somehow concerned over this new dependency addition, then I'd propose this new overload exist as part of a separate `Microsoft.Extensions.Configuration.AzureAppConfiguration.Identity` package that references both `Microsoft.Extensions.Configuration.AzureAppConfiguration` and `Azure.Identity`. I personally think that would be overkill, however.

This expands:
- https://github.com/Azure/AppConfiguration-DotnetProvider/issues/105

And apparently is somewhat of a "rollback" of this?
- https://github.com/Azure/AppConfiguration-DotnetProvider/issues/88

Looks like at the time there were some nasty dependencies on NewtonsoftJson and System.Interactive.Async that don't exist anymore in `Azure.Identity`.