fix: allow descriptions on enum refs

[JoshuaKGoldberg]

Fixes #472.

[JoshuaKGoldberg]

I'm not sold that this is a particularly good solution 🙃 it feels weird to hardcode the case for enums. But I'm not familiar enough with the codebase to have any deeper insights.

[dhvector]

I noticed the same on #466, but not related to enums. In their case, they had a property like this:

"definitions: {
  "status_block": {
    "type": "object",
    "properties": {
      "experimental": {
        "type": "boolean"
      }
    }
  }
},
"status": {
  "$ref": "#/definitions/status_block",
  "description": "..."
}

See my comment for more details on why this happens.

For a more universal fix that goes beyond just enums, I wonder about:

1. create a copy of the original json, set aside for step 4.
2. cull certain fields from any subschemas that use $ref
3. (Now the $ref resolver can make the $ref referentially equal to what it's referencing, so that json-schema-to-typescript doesn't generate a new type (or inline, depending on what version you're using?). This won't work if there are fields not culled in step 2, of course)
4. During code generation, reference the original json for things like description, which shouldn't affect type relationships, but should certainly affect generated doc strings for properties.

wdyt?

[JoshuaKGoldberg]

Honestly, although that sounds reasonable, I'm very new to this project and haven't done a deep dive into it. So if you say that's a good fix then I believe you! 😄

[bradzacher]

The property comment is in the wrong place

-   /**
-    * A first property.
-    */
    export type Shared = "a" | "b";
    
    export interface Enum {
+     /**
+      * A first property.
+      */
      first?: Shared;␊
    }␊

[bcherny]

Closing out stale PRs. Feel free to rebase and re-open if you'd like to revisit this PR.