Add DynamicGroup for runtime-defined option groups

[uenoku]

Add DynamicGroup trait-based API for creating reusable option groups at runtime.

• Add dynamicGroups HashMap to cache DynamicGroup instances
• Add getOrCreateDynamicGroup/getOrCreateDynamicGroupInstance for instance management
• Validate Groups with same name have same cases and order
• Group options by name in buildImpl to handle multiple Group objects

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• Feature (or new API)

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference).

Release Notes

Introduces a new DynamicGroup class that allows option groups
to be defined with runtime parameters instead

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash) and clean up the commit message.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[seldridge]

High-level: is there a way to do this which doesn't make everything string-based?

[seldridge]

Nit: this is fine to include up top.

[seldridge]

I don't love it due to the complexity, but this should probably implement the val naming with a suggestName method like other things in Chisel.

[uenoku]

I think I want to disallow that level of dynamic behavior. The group name is essentially user/designer facing API even when they are generated dynamically.

[uenoku]

High-level: is there a way to do this which doesn't make everything string-based?

I can provide following level of trait based interface, though I didn't like it because of the amount of boilerplate.

trait PlatformType {
  def FPGA: Case
  def ASIC: Case
}
val platform = DynamicGroup[PlatformType]("Platform", Seq("FPGA", "ASIC")) { group =>
  new PlatformType {
    def FPGA = group("FPGA")
    def ASIC = group("ASIC")
  }
}
platform.FPGA

Ideally I wanted to do following but I thought scala3 reflection would be necessary to do this.

trait PlatformType {
  def FPGA: Case
  def ASIC: Case
}
val platform = DynamicGroup[PlatformType]("Platform")
platform.FPGA

[jackkoenig]

We could make this work:

trait PlatformType extends DynamicGroup {
  object FPGA extends Case
  object ASIC extends Case
}
val platform = DynamicGroup[PlatformType]("Platform")
// or
val Platform = DynamicGroup(new PlatformType {})

Or something like that without Scala reflection

[uenoku]

62ae69d implements trait based API that uses macro. I disclose that I needed quite a bit help from AI for writing DynamicGroupIntf.scala and it might be sloppy, so it might be better to start with a previous commit that's much more simpler. Though I believe that macro correctly implements API we generally want.

[uenoku]

Simplified the builder implementation a bit more. Currently dynamic options are stored in builder separately for the early validation, but it might be redundant since they are checked in buildImpl as well.