[enhancement] Specify worst_case_throughput per-state-element

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

Currently, `--worst_case_throughput` is a global constraint, but it's natural with dynamic state feedback that typical throughput would be much better. It may be the case that the worst-case state update is taken less commonly for some state elements than for others, so you may benefit by configuring them separately. Without this, the scheduler may reduce throughput to save a register on commonly-taken-state-update because another state element's uncommonly-taken-state-update takes many cycles.

One challenge with adding such constraints is that we don't have a way to reference individual state elements. Opt can shatter, remove, or really do anything it wants to state. Coming out of IR conversion, it's all one big tuple so it's hard to attach an annotation at the beginning too.

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

Accept poor throughput or use channels to avoid using state.

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

The scheduler has a not-fragile-UX mechanism to accept constraints for each state element individually.