Alternatives to validating assertion labels at SV codegen

### What's hard to do? (limit 100 words)

@ericastor proposed some alternatives for better UX of handling #1518.

Proposal 1:
> Should we consider checking this earlier than codegen? It seems like we should error sooner rather than later...

Proposal 2:
> our other option is to just sanitize and uniquify the identifier so it'll stay SV compatible... at the cost of having identifiers
that are sometimes different than you specified. Worth doing that rather than failing this late in the process?

### Current best alternative workaround (limit 100 words)

The to-be-submitted fix will raise an error at codegen if the label is not SV compliant.

### Your view of the "best case XLS enhancement" (limit 100 words)

Let's use this issue to discuss the best option.

With the initial fix, the user will be alerted late in the flow at codegen.

With proposal 1, it is a bit of a leaky abstraction. The label is [unused at higher levels](https://google.github.io/xls/dslx_std/#fail-assert-assertion-failure:~:text=At%20higher%20levels%20in%20the%20stack%2C%20it%27s%20unused.), so if we're not lowering all the way to SV, should it be an error to have a non-SV compliant label?

With proposal 2, it may be surprising to the user to have identifiers that are sometimes different than specified. Sanitizing the labels would indeed place an onus on XLS to ensure it doesn't cause collisions in the SV.