Foreshadow how to configure an observer in lading.yaml

[goxberry]

What does this PR do?

This pull request adds types needed to be able to expose observer configuration to users via lading.yaml files in later work. It does not change the semantics of lading.yaml -- rather, this code provides enough setup to make clear a proposed observer configuration UI.

Motivation

The eventual idea is to make the observer optional and have users enable it via adding

observer: linux

to lading.yaml.

Related issues

SMPTNG-721, SMPTNG-601.

Additional Notes

Exposing observer configuration via a new field with variants seems more consistent with the design of Lading than, e.g., using a Boolean-valued field. Using an enum-valued field also enables future extension of the observer component to additional variants, if desired.

[blt]

One thing we've avoided so far is making lading.yaml configs OS specific. I'd like to keep that up. How does it strike you to have something like:

observer: {}

in the config? If present, observer is on, if not present observer is off. Or, I guess, to avoid needing to update every lading.yaml config we need to preserve the existing default-on behavior, so maybe something like:

observer:
    enabled: false

I wouldn't mind, also, dropping the use of serde flatten. I've come to feel over time this is a grave mistake.

[goxberry]

One thing we've avoided so far is making lading.yaml configs OS specific. I'd like to keep that up.

Instead of calling the existing observer Linux, would something OS-neutral like Native work?

How does it strike you to have something like:

observer: {}

in the config? If present, observer is on, if not present observer is off.

The syntax seems...counterintuitive?

I think preserving compatibility suggests that omitting an observer key in a config file would enable that component, whereas omitting keys for other components disables them. That inversion seems like a potential surprise to users. However, I don't like the idea of having to change every lading.yaml file, and if we pursued that change, I imagine we would need to write a tool that checks captures for field(s) we would expect to be present with an observer enabled.

Or, I guess, to avoid needing to update every lading.yaml config we need to preserve the
existing default-on behavior, so maybe something like:

observer:
   enabled: false

I lean towards that option for the time being, even though I think these semantics potentially cause a backwards compatibility problem later if we explore some of the ideas @GeorgeHahn has suggested. I could also see replacing enabled with an OS-neutral name for the existing observer (e.g., native: false).

I wouldn't mind, also, dropping the use of serde flatten. I've come to feel over time this is a grave mistake.

I'm curious why you think use of #[serde(flatten)] has been a grave mistake. I'm not particularly attached to using #[serde(flatten)] in this PR.