Improve type error messages and tooltips

[hasparus]

Okay this might be a small thing, but I want to add some polish (lol) to the types.

Generally, the problem we have is that our types, mostly imported from DT, may be a bit confusing.
I'd like to make Theme UI types as welcoming as possible for v1 (#832)

Related issues:

• Usage of Theme UI with TypeScript #834 (comment)
  • Add TypeScript section to the docs to explain most common tricky things people can see
• Usage of Theme UI with TypeScript #834 (comment)
  • Move all tests to TypeScript. We can't be sure Theme UI works in TypeScript if we don't typecheck our tests.
  • Get rid of generic parameter for merge. Use Theme as argument.
• Use const inside sx #907
  • Get inspired by Emotion's Interpolation and display errors on SystemStyleObject better.
• We don't support vendor properties. Why? They are defined in csstype and we actually have them inside StandardCSSProperties, but they don't come to sx prop. I can't see a reason we shouldn't support vendor properties on type level, while they work at runtime.
  • Let's add CSS.VendorProperties<number | string> to CSSProperties type.
• Add label?: string to ThemeUIStyleObject ([@types/theme-ui] SxStyleProp & Emotion's label DefinitelyTyped/DefinitelyTyped#45020 (comment))
• Rename SystemStyleObject to ThemeUIStyleObject.
  • System is a loaded word in our industry, and the name is inherited from styled-system. It might be more user-friendly to tidy up few types and use a mix of nice meaningful names and dumb straightforwad names.

---

Few notes to explain what I'm doing.

• Interfaces can be merged with interfaces of the same name.
  • https://www.typescriptlang.org/docs/handbook/declaration-merging.html#merging-interfaces
• Type aliases expand in error messages and tooltips.
• Interfaces don't allow property name conflicts in extended types.
  Intersections (&) turn a conflicting prop into never. This isn't something we often want.
  (TS Playground with example)

[hasparus]

@jxnblk Which colors in theme.colors should be required? ATM in TS types, it's background and text. Based on the tests, I'd assume none are required, but having a few may be good for interoperability.

I'm making them all optional for now to avoid changing so many tests.

[hasparus]

damn, can't Prettier decide on one style? I'll revert this change.

[hasparus]

This is starting to become pretty big, and while I didn't tackle all todos yet, it might be good to start reviewing before it becomes overwhelming.

[mxstbr]

I love this cleanup!! 🔥 So good 👍

Do you want to ship this as-is and work on the other fixes in another PR or keep this one around for a bit longer?

[jxnblk]

Which colors in theme.colors should be required?

Generally speaking, none should be required, but the color mode functionality does depend on the colors.text and colors.background keys being defined.

For the interoperability part, I think we'll want to create a "blessed" Theme interface (along with some color palette interfaces) after the TS conversion is out as an optional piece of the puzzle, but not sure if that's helpful here

[jxnblk]

Looks generally good to me -- I'd say feel free to merge this whenever and continue to iterate with more PRs, if that makes working on this easier

[jxnblk]

Not to bikeshed, but this is a much better name :)