The proposal here is to allow `Observation,subject` to refer to a DeviceMetric, not just a Device.

The intuitive argument for this is that if we allow separately modelling particular setting capabilities as DeviceMetrics - effectively parts of the overall device that have their own state - then we should also be able to make observations about them, just like we can for devices: "I looked at the red settings dial (subject) and it was in position 3 (measured value)".

One could argue that this information (which dial) should also be in `Observation.code`. However, that very same "semantic doubling" is also present when referencing a DeviceMetric in `Observation.device` in an Observation reporting a device setting. Hence, it is not quite clear why DeviceMetric is allowed in `device` but not in `subject`.

Apart for consistency, one further argument for such a change is that it would allow a clearer representation of scenarios involving multiple devices. Consider a case where I use a camera to capture the currently set sample rate on a heart rate monitor. To report this setting, it seems it would be most natural to point `Observation.subject` to the DeviceMetric representing the sample rate setting ("this is the setting the Observation is about") and `Observation.device` to the camera ("this is the device used to capture the setting value reported"). This particular example is somewhat contrived, but more realistic ones could be related to e.g. use of calibration devices (see Zulip thread linked below).

Related FHIR Zulip thread that triggered this ticket: (see comments starting Dec. 4th 2023): https://chat.fhir.org/#narrow/stream/179199-devices/topic/Device.20settings