Don't warn when 0.U used as value for 0-bit BundleLit field

[jackkoenig]

Having to add this special-case is a shame, but worthwhile. Basically, if a user writes something like:

(new MyBundle).Lit(_.field1 -> whatever, _.field2 -> (some * complex / expression).U)

We should not warn if field2 is 0-bit and that expression evaluates to 0, it's way too onerous to expect the user to handle passing 0.W to .U in this case. I think a similar thing will come up when we start warning/removing implicit truncation. It's a special-case, but it's pragmatic.

The best fix would be for 0.U to start being zero-width, but that has a ton of knock on effects and should be considered a breaking change and handled as such.

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

• Bugfix

Desired Merge Strategy

• Squash

Release Notes

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), 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.