Show all constraints when formatting the config name

[cbarrete]

This is important for OSS, who cannot add their modifiers to the hardcoded NAMED_CONSTRAINT_SETTINGS dict.

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D114419843. (Because this pull request was imported automatically, there will not be any future comments.)

[8Keep]

Please give some better description in the PR, we should update the contribution guidelines for this. I'd want at least the output and what it looks like.

I'd prefer some kind of setup where the user can set this function in their set_cfg_constructor(), so it's easy to customize if they want, with good defaults. Or, could be combined somehow with the aliases that exist there, by default?

Probably want @scottcao to think about how he'd want this to be setup too.

[lf-]

I'd been meaning to put a replacement of NAMED_CONSTRAINT_SETTINGS in set_cfg_constructor. Is that something which is possible/more advisable to solve this problem?

[8Keep]

Yes

[cbarrete]

FWIW, the custom cfg_name that I ended up writing ended up having quite a bit more logic than is conveniently handled by a list of transformers, so it's unclear to me that just expanding the list/making it configurable is the right way to go.

[cbarrete]

I've had some more time to play with this, and I agree that this is not the right approach.

I think that we need to make cfg_name configurable, but it also needs to be called (likely with more arguments) for things like transitions.
It's unclear to me what the idiomatic way of making it configurable would be.

For now, I am going to wrap cfg_constructor_post_constraint_analysis to call a custom cfg_name on the returned platform, keeping its constraints but formatting a different label.
The big downside is that again, it doesn't handle transitions.