[convenience] generalization of "pcs resource status" from ID-MATCH to PATTERN

Considering the inner (how much entities and relationships amongst them
happen to be configured) complexity of clusters tend to grow, there must
be a good query mechanism deisgned and implemented to filter only what's
indeed desired.

To retain full compatibility, what lexically conforms to `NCName`
specification of XML would be understood as full resource `id`
specification as used to be.

Easy and natural extension: globs (would consider self-understood, but
can explain on demand).

Then, we can consider another natural extension: whenever semicolons
are spotted in the pattern provided, they are understood as a filter
nn agent type, e.g. `ocf:heartbeat:Dummy`, `:Dummy`, `::Dummy`,
possibly combined with globs: `systemd:*`.

Then, it becomes really interesting, since we have still some initial
easy to type characters that cannot occur with either of the above
pattern decompositions.

* * *

I won['t restrict the fantasy here, I'll just pick what I'd like to
see personally. Let's say the escape-access character is % (can be
any other, though, apparently, shell-sensitives characters like
a bang `!` would rather be avoided).

* `%ticket` would select any resource immediately affected with
ticket constraints, as with `crm_ticket -c` that is yet to
receive an entrypoint in pcs, anyway

* `%ticket:TICKET`, ditto with `crm_ticket -c -t TICKET` for
a single, named, glob-free ticket

- when `TICKET` contains a glob, result would be a sum of
running `crm_ticket -c -t T` over all `T` that match
the glob

- TICKET can possibly also be specified as `(special or ordinary*)`
that would respectively concerned a ticket named `special`
and tickets matching glob `ordinary*`

* level 100: `%ticket:[TICKET]@CLUSTER-SLASH-SITE-IDENTIFIER`
- filter resources to show just those that are constrained
with all (given per spec) tickets whose counterparts are
enabled (respective tickets granted there) at given
site -- this may sound overcomplicated, but it will be
blissful for typical mutually-excluded-mirrors use cases
(you will immediately get to see which resources are
expected to be covered by a primary site if there's
such a distinction and you are currently running this
command from any "secondary" one, for instance, hence
you can check whether you see "stopped" or "slave"
status with these in the context of a local cluster)

Apparently, these predicates themselves shall be eligible for
logical combinations as well. It would then be natural to
retain the current logic of implicit _OR_ (`show FULLID1 FULLID2`).

Complicated example:

```
pcs resource status 'ocf::IPaddr2 and ms-ip-* and %ticket:t-ip-** and %ticket:@10.2.3.4'
```

is a verbose way of querying this:

```
pcs resource status 'ocf::IPaddr2::ms-ip-*%ticket:(t-ip-*@10.2.3.4')`
```

and it asks to list all local-cluster resources matching a glob `ms-ip-*`
in `id` that are instances of ocf::IPaddr2 resource agent(s), directly
connected to `t-ip-*` glob-matched tickets that are currently known to
be active site specified with 10.2.3.4 address.

It's all just a trivial applied set theory, moreover supported nicely
in Python :-)

* * *

As mentioned, there would be a lot more predicates to come up with here.