add get_guest_config_property IPCC method

add get_guest_config_property IPCC method

This adds a new method to our IPCC interface.
It's a helper to get a property of a single or all guests.

It is restricted to only look at the current config state only, i.e.,
no PENDING changes and no snapshots, this is by design and wanted.
It uses the strict config format to be quick and return/continue
early, those restrictions are imposed by
PVE::QemuServer::parse_vm_config, and the container counterpart, it
mostly boils down to the following regex:
/^([a-z][a-z_]*\d*):\s*(.+?)\s*$/
and the fact that this is applied directly on the config lines (no
whitespace trimming, in any way, happens before)

Motivation for this work is to get the lock state of all guests
_quick_, allowing us to pass this info in our resource call, and
enhance the tree view of our Web User Interface with that
information. It was kept a bit more general, without bending the code
to much. The call returns a serialized JSON object with the format:
VMID => { PROPERTY => PROPERTY_VALUE }
if the property was found in VMID configuration, a empty object will
be returned if it was not found.

If one passes 0 to the request all VM configurations will be
searched, only those with a match will be returned, in the same
manner as above.

So why a IPCC call and not perl handling of this? Well performance.
Dominik's proposed a perl + cfs_read_file approach[0], while this is
relatively short and in the (mostly) safer perl land it's pretty
slow, especially on first connections. The idea for this existed
since quite a bit in my head, but Dominik's patch put it in front and
a prototype of this was born soon after that, initial evaluation and
performance comparison showed a speedup of >100 times at the initial
gathering, as [0] really benefits from the ccache afterwards, and
that _is_ a cache which gets often used and hit more "serial runs"
(i.e., in same worker) make his approach more reasonable, though.
But after a bit of work this came in not to ugly shape, and here the
numbers, with 10005 VM configs, all "real" ones with about 502 bytes
space usage, and all with a lock in the worst place, at the end.

Legend:
C0 : how many "serial runs" took place, i.e., how many runs in the
     same worker
C1: IPCC (this) approach total runtime in ms
C2: IPCC (this) approach per-run runtime in ms, i.e., C1 / C0
C3: Perl + cfs_read_file ([0]) approach total runtime
C4: Perl + cfs_read_file ([0]) approach per-run runtime, i.e., C3 / C0

Data:
C0	  C1 	  C2 	   C3  	  C4
1	18.31	18.31	3570.29	3570.29
2	31.51	15.76	3717.69	1858.84
3	44.19	14.73	3821.84	1273.95
4	58.54	14.63	3950.24	987.56
5	70.31	14.06	4071.42	814.28
6	95.29	15.88	4175.95	695.99
7	95.87	13.70	4192.35	598.91
8	111.81	13.98	4346.84	543.36
9	120.84	13.43	4432.13	492.46
10	134.52	13.45	4554.25	455.42
11	149.74	13.61	4673.71	424.88
12	161.13	13.43	4797.56	399.80
13	172.74	13.29	4892.15	376.32
14	180.63	12.90	4951.17	353.66
15	199.04	13.27	5034.51	335.63

So, initially C beats Perl (not really correct wording, but hey) by
>200 times. But, on the second run we immediately see that while IPCC
scales almost linear the perl one doesn't, it really benefits from
the cache now, while initial call needed 3.5s this "only" needs ~200
ms more. But 200ms is still quite a bit of addition to an API call,
10k VMs are not seen to often in the wild, I guess, albeit it's
easily possible with setups using a lot of containers, here we know
about users having ~1500 CTs on only two nodes, so not completely
unrealistic either.

[0]: https://pve.proxmox.com/pipermail/pve-devel/2019-February/035830.html

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>