[patch] Rewrite Types Section

[mmaloney-sf]

This PR is a moderate rewrite of the entire Types section.

This is best reviewed by building the PDF and reviewing paragraph by paragraph.

Here are some highlights:

• Uninferred types are mentioned in their own section. (Both width and reset inference).
• The section on zero-width integers is abbreviated. (It warrants mention, but doesn't need so much ink spilled)
• Analog type is scooched down.
• Small code formatting of FIRRTL (eg, spaces between braces in bundle types)
• Reword section on flips with bundle types.
• Rename "Reference Types" to "Probe Types"
• Move several examples of FIRRTL programs using probes out of the Probe Types section and into the probes section.

[mmaloney-sf]

@darthscsi I rewrote the Constant Types section as best as I could.

Being such a massively cross-cutting feature, it's hard to spec out in just one section. I think the rewritten version touches on all points from the original:

• include a (tentative) rationale for the feature
• remove the example of a bundle with a nested const -- it's theoretically interesting, but not really speced out, so let's not draw attention to it
• mention that const doesn't mean static -- these things might be unknown because of input ports
• explain the rules everyone will agree one (literals are const, prim ops of const are const, muxes of const are const).
• Gesture at how const T can be implicitly coerced/cast to T.
• Gesture at the connect rules for const (source must be const, any conditionals must have constant conditions)
• Reword "indexing" into aggregates in terms of subcomponents (I haven't written the subcomponents section yet, but bear with me please!)
• Moved "A note on implementation" to the ABI doc.

Thank you @seldridge for letting me bounce my thoughts off of you.

[mmaloney-sf]

One big addition at the last minute:

I define a Connectable Type as a type which may appear as the type of an expression which may participate in a connect statement.

Connectable types appear internally in the FIRRTL MLIR dialect. They affect how components are split up when lowering to Verilog.

Currently, I only rewrote the enumerations section in terms of these. (Namely, the types of variants must be connectable and passive). But as I get to the section on Connections, we can apply this definition cleanly there.

This definition will also help us untangle some thorny issues in FIRRTL, which add a disproportionate amount of complexity to the spec:

• what it means for non-hardware to be packaged in aggregates (eg, bundles of probes or properties), and
• how we should think of the Analog type

[mmaloney-sf]

I forgot -- I'm a bit stuck on the section on Probes and Type Inference.

@dtzSiFive Can you advise me on how to handle this section?

[mmaloney-sf]

Just to clarify since @seldridge had left a number of comments I closed without addressing:

The section on Type Inference and the section on Type Equivalence were left mostly unchanged. Both require a lot of care to reword without changing the meaning. Furthermore, the latter is acutely underspecified.

I think all of the comments I closed without fixing are worthy of being addressed. I am just postponing that work for a separate PR, so it doesn't get lost while picking all the low-hanging fruit.