Allow customization of prop serialization/hydration by supplying custom ser/des functions

[lionel-rowe]

Example:

type CustomPropTypeHandler<T, S extends JsonSerializableValue> {
    is(x: unknown): x is T
    serialize(x: T): S
    hydrate(serialized: S): T
}

// prop type I want to make serializable
class Foo {
    constructor(public readonly bar: string) {}
}

// handler
const fooPropTypeHandler: CustomPropTypeHandler<Foo, string> = {
    is: (x) => x instanceof Foo,
    serialize: (x) => x.bar,
    hydrate: (bar) => new Foo(bar),
}

// middleware
app.use((ctx) => {
    ctx.customPropTypeHandlers.push(fooPropTypeHandler)
})

// island component
export function FancyDiv(foo: Foo) {
    <div>{foo.bar}</div>
}

// server-side component/page
<FancyDiv foo={new Foo('hello world')} />

This probably wouldn't make much sense for mutable data, but it'd allow passing around richer data types. It could even work for stringified functions, with the caveat that there'd be footguns, which is less of an issue if it's a userland solution rather than officially supported.

My current, significantly less footgun-prone use case is that I want to add ser/des support for polyfilled Temporal classes.

[bartlomieju]

Good news — the internal infrastructure for this already exists. Fresh's jsonify system accepts custom Stringifiers and CustomParser objects (that's how Signal and Computed serialization works internally in src/jsonify/stringify.ts and src/runtime/client/reviver.ts).

The missing piece is a user-facing API to register custom serializers. The internal types:

// Already exists in stringify.ts
type Stringifiers = Record<string, (value: unknown) => { value: unknown } | undefined>;

// Already exists in parse.ts  
type CustomParser = Record<string, (value: any) => unknown>;

This would need:

1. A way to register custom handlers (on the App instance or via config)
2. Plumbing to pass them through to the server-side stringify() call during rendering
3. Plumbing to pass them to the client-side parse() call in the reviver

The proposed API in the issue is reasonable. Labeling as a feature request.