Define ResetCrossingType and use with BlockDuringReset in TilePRCIDomain

[hcook]

This PR combines and merges the effects of #2618 and #2623 while also partially reverting #2611. The overall goals are:

• Avoid tunneling the "raw" subsystem reset into RocketTile, instead, move all logic requiring raw reset into the TilePRCIWrapper
• Said logic largely takes the form of registers that block tile outputs from appearing valid while the tile is being held in an extended reset, in which case those registers need to be asynchronously reset for certain ResetSchemes (when a ResetStretcher is injected) and then they need to maintain the blockage for the duration of any stretched reset.
• TileResetDomain is added to manage diplomatic control of the Tile's reset input. All other clock crossing logic in TilePRCIDomain goes back to being on the raw subsystem reset (but still on the tile clock domain). TileResetDomain is inlined by firrtl to prevent further disruption to the module hierarchy.
• ResetCrossingType is defined to be analogous to ClockCrossingType, the two defined reset crossing types are currently NoResetCrossing and StretchedResetCrossing(cycles: Int)
• The diplomatic CrossingHelper functionality for TL and Interrupts are extended to also deal with ResetCrossingType
• Specifically, for StretchedResetCrossing they will inject BlockDuringReset logic in the scope where the helper is invoked; in this specific case, that scope is TilePRCIDomain, ensuring the logic gets the raw reset.
• Various other minor parameterization cleanups and helper nodes.

@aswaterman, @ernie-sifive can you double check that my changes to the actual BlockDuringReset logics look kosher?

Type of change: other enhancement

Impact: API modification

Development Phase: implementation

Release Notes

[ernie-sifive]

I think the reset treatment matches what we discussed.

[ernie-sifive]

So this moves traceNexusNode to the PRCI layer so it can be blocked during reset. There's some technical debt to apply the same treatment to traceCoreNexusNode (below). This bundle doesn't have a valid signal. Either we will have to add a valid to TraceCoreInterface (bending the definition of this interface from the RISC-V Trace Spec) or add another form of BlockDuringReset specifically for this (which would zero out iretire and itype).

[hcook]

Thanks for the feedback, I was wondering a bit about whether that bundle needed to be blocked too. There's almost certainly a way to have each Bundle subclass define it's own blockMe function (name TBD) that returns a copy of itself but with certain signals tied low. You still have to make one NexusNode per type of bundle bridge, but it's at least very generic code to ensure that the blocking occurs in a type-specific way.