Allow custom styling for secondary titles

[epage]

Primary titles (first title of a grouo) are bolded.

Secondary titles are currently left alone.

Apparently, rustc allows styling of secondary titles,

Source: rust-lang/rust#128849 (comment)

So we need to allow this for parity with rustc

[epage]

#243 removed Level::pre_styled_title.

I dislike the name pre-styled. I don't remember what other name I had considered when @Muscraft and I last discussed this.

One design consideration is that we don't need the Primary Title to be styled, only the Secondary Titles. We probably should make this clear in the API since we probably do not want people to match our auto-styling of the Primary Title with a pre-styled Primary Title.

So one thought for an API is to have

• Level::primary_title: documented as only allowing unstyled text and its for the title of the first group
• Level::secondary_title: documented as allowing styled text and its for later group titles

[epage]

Concerns with the proposed names:

• Is this a repeat of Level.header vs Level.title is confusing #196? No, because the names communicate the distinction in their use
• What about people misusing where primary_title and secondary_title can be used?
  • We could further clarify that with asserts.
    • As asserts are not able to be handled by the callers, is it appropriate in a low level library like this?
      • Yes, because this represents a development-time error. So long as the user is likely to see the assert before releasing, that is fine. In this case, the list of Groups would likely need to be generated in a very weird way to make a mistake on when each of these can be used.
  • Handling this through less opinionated names has a similar problem

[epage]

Alternatives

• styled_title("")
• title("").styled(true)
  • Downside: makes titles interpretation dynamic
  • Upside: de-emphasizes custom styling for titles

These are lower-level, mechanism focused names. The main problem is if someone uses these as the title for the first Group, they won't get the correct formatting. They can try to recreate it but that becomes a moving target.

[epage]

There are fundamentally two questions for the API

• Should the primary / secondary built-in styles be done implicitly or explicitly?
• Should the user styling be allowed everywhere or only on secondary titles?

For example,

• title / pre_styled_title` took the approach:
  • title inferred the primary vs secondary built-in styles
  • pre_styled_title could be used anywhere, allowed the user to create any primary or secondary style they wanted, but if they wanted the primary style to match the built-in, they'd have to do extra work
• primary_title / secondary_title would take the approach
  • Styles are chosen implicitly while only custom styling was allowed in the secondary (which was fine since its built-in style is "plain")