Plan for modeling of unusual types

This issue is to track ideas for how we might model JSON Schema types in Rust. The particular goals are to model the types as closely as possible such that only valid states are representable in Rust. Here's an example:

{
  "type": "object",
  "minProperties": 1,
  "maxProperties": 1,
  "additionalProperties": {
    "type": "string"
  }
}

A valid JSON object might look like this:

{ "foo": "bar" }

It is, in other works, a single key-value pair (both strings). Absent the min/max property count constraints, we would model this in Rust as a Map of some kind (e.g. HashMap<String, String>. With those constraints this could be precisely modeled as a tuple of Strings:

struct GeneratedType(String, String);

This is great in that users can only generate values that conform to the schema.

The wrinkle is that the default serialization of SomeType("foo".into(), "bar".into()) would be ["foo", "bar"]. For this type--and others we need to have both a representation in Rust and the proper se/deserialization. One way to address this is with "helper" types that implement the appropriate Ser/De functions:

struct GeneratedType(json_helper_types::ObjectSingleton<String, String>);

Explicit, inline types might be simpler to use and understand, but managing the serialization functions would be more cumbersome. As such I propose the following:

• Create a new crate (within this workspace?) where we create types that match these special cases
• Create a setting for typify that lets consumers opt-in or opt-out of its use (opting out would render less-specific, less-precise types)
• Eventually inline the types and rely on the crate for serde implementations

No files, tests, or entry points are named. Begin by reviewing the workspace and existing JSON Schema-to-Rust modeling; the proposal covers a helper-types crate, an opt-in or opt-out setting, and eventually inlining types while relying on the crate for Serde support.