Include Jwt Authentication Requirement Rules in Service to Service JWT Validation

#### Feature Description

I was glad to see the recent addition of the JWT provider configuration directly in Consul configs:
https://developer.hashicorp.com/consul/docs/v1.16.x/connect/config-entries/jwt-provider

In order to use it, we would also need to be able to provide the "requirement rules" that triggers the JWT validation.
Our adoption of JWTs are gradual. Services that demand them for certain actions can make those assertions. The presence of JWTs in requests is pretty sparse at the moment, even for the same service. Some actions on a service allow anonymous access, others don't. We cannot turn on an all or nothing solution. We force JWT validation **only** when JWTs are present in requests.

Today, we currently accomplish this same behavior by utilizing the `envoy_public_listener_json` escape hatch. This works fine, but has several downsides. It's quite the override just to get service to service traffic to have JWT validation baked in.
With this override in place, we no longer get some of the benefits of dynamic configuration provided by global defaults such as adjusting timeouts. Alterations done globally must be duplicated in the `envoy_public_listener_json` too - at least in how we have implemented it.

#### Use Case(s)

Similar to the link above for configuring the JWT Provider's locations, I'd expect to configure the requirement rules in a similar way.

For example:

- Specify a required/optional flag for each location. If specified, the envoy proxy's requirement rules would be auto created on our behalf.
```hcl
Kind = "jwt-provider"

Locations = [
{
Header = {
Name = "Authorization"
ValuePrefix = "Bearer "
Forward = true
Optional = true # New Field
}
},
{
Cookie = {
Name = "MyJwtCookie"
Optional = true # New Field
}
}
]
```

This could create the rules for envoy proxy such as:
```json
{
"match": {
"prefix": "/",
"headers": [
{
"name": "Authorization"
}
]
},
"requires": {
"provider_name": "the_auto_generated_provider"
}
}
```

- Or allow us to specify the rules via HCL if that is the more straight forward way to accomplish it:
```hcl
Rules = [
{
Prefix = "/"
Headers = [
{
Name = "Authorization"
}
]
},
{
Prefix = "/"
Headers = [
{
Name = "Cookie"
StringMatch {
Contains = "MyJwtCookie"
IgnoreCase = true
}
}
]
}
]
```

Start with the JWT provider configuration documentation and the existing envoy_public_listener_json escape hatch described in the issue. Compare the proposed location-based and HCL Rules approaches, then define the supported configuration and validation behavior; done means service-to-service JWT requirement rules work without the override.

Written by the indexing model from the issue text.