TECH TASK: support cascading yaml configs for signalc

It would be nice to read signalc's configs from cascading yaml files. (As inspired by https://github.com/bodylabs/misty-config)

(Why do this when we already have overrideable configs in the code? Mainly b/c of wanting to be able to swap out configs without recompiling. But also: yaml configs are a nicer / more convenient interface that would be easier to debug and be easier for downstream users of the library version of signalc to work with.)

Sadly, 2 attempts to implement this in a prior MR failed:

1. this approach based on parsing YAML to intermediate data classes with nullable fields works but all the boilerplate necessary to convert from the intermediary representation to the actual config schema (in which no fields are nullable) makes it unacceptably unwieldy to maintain: ff5adac3
2. this next approach uses a HashMap<String,Any> as the intermediate representation but produces insurmountably complex runtime and/or compile errors when trying to parse from yaml to the intermediate representation, due to difficulties with providing polymorphic serializers for Any and type erasure reducing our hashmap to HashMap<*,*>): a134f3af

We leave these 2 attempts as breadcrumbs for a future intrepid developer to pick up where we left off. :)

---

For the record, @aguestuser 's money is on a modified version of (1) in which we implement some YamlNode class that:

• is inherited by all config data classes
• uses reflection to implement unwrap without needing to enumerate every field (and borrows the logic for (2) of substituting env vars if a field is a string)
• borrows from the merge logic of (2) to recur if a field is a YamlNode, otherwise substitute any non-null fields from other
• perhaps works as an annotation that can generate the code for any SomeConfigYaml data class from a vanilla @Serializable(SomeConfig)