[ur][common] pretty printing for props

[pbalcer]

[ur] introduce enum associated types and use it for props
Many UR functions use enum tags alongside opaque (typically void *)
pointers to construct an algebraic data type. This is useful because
it allows for creating function arguments that can be one of
several types of values. However, this approach, at least in C,
is not very typesafe. It's fairly easy to make a mistake that
can't be easily caught at compile time (and even at runtime).

To help with that a little bit, at least on the spec side of things,
this patch introduces optional 'typed_etor' and 'typename' qualifiers.
An enum with typed etor requires that all its values have specify
a type in their 'desc' field. The typename can be used to tag
opaque pointers with a tag field name.

Typed_etors are checked by codegen scripts, whereas correctness
of typenames is indirectly enforced by the code itself (won't compile
if it's wrong).

[common] use associated type information to serialize info_t types

This patch uses the typed etors and typename information to pretty
print *_info_t prop names, which otherwise are opaque pointers.

[pbalcer]

Example output for urDeviceGetInfo:

urDeviceGetInfo(.hDevice = 0x80800002, .propName = UR_DEVICE_INFO_TYPE, .propSize = 4, .pPropValue = 0x7ffd257e1720 (UR_DEVICE_TYPE_GPU), .pPropSizeRet = nullptr) -> UR_RESULT_SUCCESS;
urDeviceGetInfo(.hDevice = 0x80800002, .propName = UR_DEVICE_INFO_NAME, .propSize = 1023, .pPropValue = 0x7ffd257e1830 (Null Device), .pPropSizeRet = nullptr) -> UR_RESULT_SUCCESS;

[pbalcer]

This is annoying to rebase and breaks with almost every UR change, so I'd appreciate a prompt review.

[pbalcer]

@kbenzie I'm changing the spec format a little bit (described in YAML.md), can you take a look at those changes?

[kbenzie]

LGTM