Allowed AsExpression-like type assertions on object literal shorthands

[JoshuaKGoldberg]

This PR adds a type?: TypeNode property to the ShorthandPropertyAssignment interface, and adds it to the allowed tokens for shorthand property assignments in parsing. In checking, if a member type is declared on a shorthand assignment, it is used instead of the name.

I was uncertain how best to describe this AST behavior. Two other options I decided against were:

• Have the node be an AsExpression instead of a ShorthandPropertyAssignment: would break the existing assumption that all properties on an ObjectLiteral contain a .name.
• Have the node contain an AsExpression: the name of the shorthand node would point to the same area as the expression's .type.

Open issues:

• Intentionally leaves out the case of <type>name type assertions. I would love to get to those in a separate PR, but it looks like those would need different changes. Same PR for coherency or different PR for smaller changes?

• An object shorthand's type being before its name would imply it's a type assertion, while being after the name implies it's an as assertion. That's the smallest API change but also a little hacky feeling. Would love to know of a preferred way... Perhaps having either an asType and assertionType but not both?

• Is asType.parent = node; the correct way to set up the child node's .parent? Without that line, in local tests it would fail on a union type (e.g. age as number | string) with:~~

  TypeError: Cannot read property 'kind' of undefined
      at getAliasSymbolForTypeNode (C:\Code\typescript\lib\tsc.js:27445:31)
  

  ...which maps to node.parent.kind.

  There's a test failing for it, but I couldn't figure out where the right place is.

  Found it: added it to forEachChild.

Fixes #13035.

[JoshuaKGoldberg]

After cc9f921, confirmed this worked in VS Code. I've never added such a visible feature before, though, so I'd love pointers if I'm missing test cases!

[typescript-bot]

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

[JoshuaKGoldberg]

@RyanCavanaugh I would still like this to be merged in, please!

[RyanCavanaugh]

@JoshuaKGoldberg #13035 hasn't been approved yet; we can't accept PRs for syntax additions outside that process