Implement typeName API for stable Module names (backport #3130)

[mergify]

typeName is a new member of Data types which specifies a default, non-ambiguous name of its type. This is useful for problems like generating a descriptive name for a Chisel type, as it allows modules (e.g. Queue) to use this naming information for their own desiredName.

As a motivating use case, Queue modules now have a default name based on the depth parameter of the Queue as well as the generated typeName of the Chisel type passed to it. For example, Queue4_UInt4 describes a Queue of size 4 which takes a UInt(4.W), and would be the default desiredName of such a queue.

User-defined types like Bundles should override this feature if needed to diversify the names of Modules that use them, preventing situations like multiple Queues all sharing the same name and having unstable names as a result.

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 state the API impact?
• Did you specify the code generation impact?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• new feature/API

API Impact

Adds a new public-facing feature to Data

Backend Code Generation Impact

Module names in FIRRTL will now include the parameter information of their respective Chisel modules in their names (via overriding desiredName), and consequently Verilog names will differ as well.

Desired Merge Strategy

Squash and merge

Release Notes

This gives a flexible way to generate a stable name for a Chisel type, which is useful for problems like generating stable names for Modules and Queues

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels?
• Did you mark the proper milestone (Bug fix: 3.5.x or 3.6.x depending on impact, API modification or big change: 5.0.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), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

---

This is an automatic backport of pull request #3130 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 0ce115e has failed:

On branch mergify/bp/3.6.x/pr-3130
Your branch is up to date with 'origin/3.6.x'.

You are currently cherry-picking commit 0ce115e9b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   core/src/main/scala/chisel3/Aggregate.scala
	modified:   core/src/main/scala/chisel3/Bits.scala
	modified:   core/src/main/scala/chisel3/Data.scala
	modified:   core/src/main/scala/chisel3/experimental/Analog.scala
	modified:   src/main/scala/chisel3/util/Arbiter.scala
	modified:   src/test/scala/chiselTests/BetterNamingTests.scala
	modified:   src/test/scala/chiselTests/CloneModuleSpec.scala
	modified:   src/test/scala/chiselTests/ToTargetSpec.scala
	modified:   src/test/scala/chiselTests/experimental/DataViewIntegrationSpec.scala
	new file:   src/test/scala/chiselTests/naming/TypenameSpec.scala

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   docs/src/cookbooks/naming.md
	both modified:   src/main/scala/chisel3/util/Decoupled.scala
	both modified:   src/main/scala/chisel3/util/Valid.scala

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jackkoenig / name: Jack Koenig (1f666fe, cf9660c)

[jackkoenig]

The 1 part of this that we shouldn't backport are the overrides of desiredName since that's a fairly large change to the names of modules (and thus generated code). It wouldn't really be appropriate for a minor release like v3.6.1, users can bump to 5 or 6 if they want that change.