Split 'Composite types' into 'Structs and Messages' and `Optionals'

[anton-trunov]

It seems we don't have too many composite types at the moment, so bundling basically two entities together is not making much sense and decreases visibility of the aforementioned types. Also, when we add a 'Maps' chapter these three will look organically together in the table of contents:

• ...
• Structs and Messages
• Optionals
• Maps
• ...

[novusnota]

If anything, I'm thinking of adding maps (#135) into the Composite types page, as it technically counts. But your idea on visibility also makes sense, so I'll try locally applying it too to see which approach is best (maybe neither, as we'll discover alternative approaches)

[anton-trunov]

Yeah, composite types also would work, however I'd give these fundamental things more visibility (the less clicks or taps it takes to get there the better)

[novusnota]

Oh, I figured it out: we need to gracefully merge composite-types.mdx with types.mdx, while moving Structs, Messages and Optionals into their own pages. I'm on it :)

types.mdx would look like:

• description
• primitive types
  • description
  • brief sub-sections for each primitive type (with links to big pages, like Integers)
• composite types
  • description
  • brief sub-sections for each composite type (with links to big pages for each, as each deserve those).