Support partial wildcards in intentions.

#### Feature Description
Intention validation, documentation, and source code all point to not allowing intentions with wildcards in names or source names.

For example, in source, several comments document:
> ... but only the full value can be a wildcard. Partial wildcards are not allowed.

We have designed around this limitation a few times now, but having native support would simplify things quite a bit for us.

#### Use Case(s)

1. Our automation at times creates a few jobs to represent the same batch app, but with separate cron schedules and separate arguments being passed in. This job may be the "OrderMainenanceJob", for example. A single "app" that can perform different, similar behaviors based on the arguments passed in at run time. So we may have this app scheduled to do task A every 10 minutes, and task B every hour.

The Nomad jobs to represent task A and task B may be named `ordermanagementjob-a` and `ordermanagementjob-b`. We must make their Consul service name be `ordermanagementjob` instead of one that better matches the job's actual name because we don't want to manage the several individual intentions of `ordermanagementjob-a → orderservice` and `ordermanagementjob-b → orderservice`.

It would be better to manage the single intention of `ordermanagementjob-* → orderservice`.

1. For the sake of running integration tests, a test sandbox, or tightly coupled apps within a single job, we may have dozens of services in a single job that fundamentally just need to communicate with each other with a few exceptions. These services in a single job do not share Nomad groups to allow better distribution and scheduling of the whole job across the data center. So to communicate with each other, they must be setup as Consul services, which then gets us into the realm of managing intentions for them. Since they all sit in the same job, we prefix their service names with a unique identifier shared across all of them. This ensures we can deploy multiple flavors of similar jobs that will not directly conflict with each other.

It would be very helpful if we could have wildcard prefixes in this situation. Given my job with the name of `monsterjob-12345` that contains 15 apps / services with service names like `monsterjob-12345-orderservice`, `monsterjob-12345-paymentservice`, `monsterjob-12345-processingservice`, etc. Building the combinations of intentions here without partial wildcards in a default deny all service mesh is a bummer.

It would be great to have a single wildcard intention like `monsterjob-12345-* → monsterjob-12345-*` or `monsterjob-12345-* → *` or `* → monsterjob-12345-*`.

I'm primary documenting this one for integration testing or transient service sandbox "environments" for the sake of development and testing. While even though we can automate the creation of dozens of combinations of intentions for a job, we then have to worry about the cleanup and what happens when cleanup fails leaving us with growing dead intentions. Having a single intention to manage, even when automated, is better than doing the same with 30+ intentions.

While I know the above items have alternative solutions such as namespaces, different data centers, or those alternatives mentioned above, from our point of view, partial wildcards in intentions would allow us to simplify things or to use less resources.

The issue points to intention validation, documentation, and source comments as the starting areas; read them together to locate the current full-value wildcard restriction. Define and validate the intended partial-wildcard behavior for the examples, then update the relevant documentation and validation coverage so the supported patterns are clear.

Written by the indexing model from the issue text.