Make tracking overrides work with builders

Currently tracking overrides are only working with the legacy builder.

All drivers that are initialized with a different builder in src/targets/common/_builder can't be used with tracking overrides.

The major difficulty is that the initialization of most xrt_devices requires a special setup that can't be easily serialized in a configuration file (e.g. a Valve Index Hand Tracking xrt_device requires one of vive,survive,lh drivers and to get the camera frames from it).

We should solve this by writing a sort of hardware abstraction layer. The builder code should be almost entirely left alone, the only difference would be that builders don't create xrt_devices anymore, but get them from this common hardware abstraction layer.

added enhancement label

assigned to @haagch

My first design idea for this was to just make one giant hardware object that knows about all supported hardware with functions for out of tree drivers to add their stuff but that doesn't feel right.

Instead, I think what we're missing is an xrt_driver object type. Right now an xrt_driver for e.g. steamvr_lh seems redundant because we have a builder for that, but that's because the builders do too much, namely creating the xrt_devices, which includes encapsulating the knowledge how to create the xrt_devices.

I think what we really need is to make it possible to ask an xrt_driver to create a specific kind of xrt_device in a generic way. For example you want to be able to ask a steamvr_lh xrt_driver to give you its xrt_device for the cameras. That way you can set up the pipeline for slam tracking or hand tracking in a generic way by connecting them in a builder generically. The same would go for all devices. In the builder you wouldn't call steamvr_lh_create_devices anymore, you would call something like xrt_driver_get_or_create_xrt_device(xrt_driver_list, "steamvr_lh", XRT_DEVICE_GENERIC_HMD). (not the best example as steamvr_lh_create_devices doesn't need special setup, but some other create functions need cameras, etc.)

This function could handle tracking overrides, or perhaps have a parameter whether tracking overrides should be allowed (maybe sometimes you want the real device). The life time of the tracking override device would need some extra care here though.

+1 from me for a clear xrt_drive interface to whip some order into the builder.

Would allowing mix and match (HMD from one constructor, controllers from the others) be allowed?

It would enable writing a generic builder that could do it, for example configured with a json config file. The idea is that a function like xrt_driver_get_or_create_xrt_device would only take parameters that are easily serializable into a config file like strings and enum values, and not xrt_device objects.

marked this issue as related to #459