Investigate KDL document language

the KDL document language is an intriguing alternative to formats like JSON, YAML & TOML. To quote the [KDL docs](https://kdl.dev/):

> A KDL node is a node name, followed by zero or more "arguments", and children.

```sdl
title "Hello, World"
```

> You can also have multiple values in a single node!

```sdl
bookmarks 12 15 188 1234
```

> Nodes can have properties.

```sdl
author "Alex Monad" email="alex@example.com" active=true
```

> And they can have nested child nodes, too!

```sdl
contents {
section "First section" {
paragraph "This is the first paragraph"
paragraph "This is the second paragraph"
}
}
```

One of the things that first struck me is how "shell-like" it reads, and that it looks like it would be easy to write scripts in, making it a nice fit for BitOps configurations. Since it has explicit scope boundaries there's less need deep nesting like in YAML. Also, as it has a concept of node type, there's less ambiguity about the type of an object relative to YAML, where you need to infer the type of an object based on _where_ it appears in the data hierarchy.

The specification is still quite young, but there's a fair number of parser implementations. If we end up needing particular features from YAML it's possible we could still get them added to the standard.

A developer should explore what BitOps functionality might look like through a KDL based interface, any advantages or shortcomings, and the difficulty of supporting that interface in addition to YAML in a future version.

Start with the linked KDL specification and compare its nodes, properties, children, and typing model with BitOps' existing YAML-based configuration interface. Document the potential advantages, shortcomings, and the effort required to support KDL alongside YAML; completion should provide a reasoned feasibility assessment rather than a code change.

Written by the indexing model from the issue text.