How does Wing represent jsii "object" / serializable types?

Wing should have a type, or group of types, that are defined as serializable. These types are useful for cloud application development because when a function call receives an argument in Wing, it's possible the function will be executed on another machine in the cloud. In these cases, there needs to be a serialization mechanism for the argument to be passed without data loss.

For example:

class Person {
  init(name: str) {
    this.name = name;

    PersonRegistry.register(this.name, self);
  }
  addNeighbor(neighbor: str) {
    PersonRegistry.addNeighbor(this.name, neighbor);
  }
}

Since this class mutates class-external state in its methods (through PersonRegistry), it's not possible to send a Person class instance between cloud resources without introducing problems. For example, if cloud function A created a Person instance and gave it to cloud function B, how would B calling addNeighbor update the original PersonRegistry in A's runtime - in a way that adheres to ACID (or at least doesn't surprise users)? I think this is currently out of scope for Wing.

Open questions:

1. If we import a JSII library in Wing code that uses this type, how will it be modeled in Wing's type system?
2. Would it be useful to make this a native/primitive type in Wing? How would its semantics work (e.g. what are the valid subtypes / supertypes of this type...)? How does this solution (designating a type that represents any serializable structured value) compare to alternatives, like adding a Serializable interface / trait?

No file, test, or entry point is identified in the issue. Start by examining Wing's type-system and jsii integration to determine how serializable object types are currently represented. Done would require an agreed semantic design for imported jsii types and any native or interface-based Wing type, rather than a narrowly scoped edit.