Fix unnecessary space around power op in overlong f-string expressions

[MichaReiser]

Summary

Fixes #14487

The RemoveSoftLineBuffer should remove any content "expanded"-only content. For example, it removes all soft line breaks and replaces soft_line_break_or_space with a space.
However, it didn't remove any if_group_breaks usages.

This PR extends the RemoveSoftLineBuffer to also remove any content inside if_group_breaks. This is slightly more complicated because it requires removing multiple elements and
if_group_breaks call can be nested.

Test Plan

Added test

[github-actions]

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[dhruvmanila]

This is just for my understanding - the reason this exists here in addition to being in should_drop as well is because of the Default state which would mean that the should_drop will return false. But, we don't need to match against EndConditionalContent as it'll be taken care during the should_drop check.

I wonder if this could be simplified to only have a counter where any value > 0 indicates that we're in "if_group_breaks" and 0 indicates that we're outside of it. Or, do you foresee any other states that we might want to track in RemoveSoftLineBreaksState?

[MichaReiser]

We could probably just use one usize for it where 0 indicates that we're inside an if_group_breaks if we change the implementation to start the level at 1 instead of zero.

However, I do like the explicit state because it documents what's going on here.

[dhruvmanila]

I'm fine with the explicit state, I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing. I had to look at it a bit closely to understand why this is the case.

[MichaReiser]

I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing

I don't think that would change by switching to using an usize instead of an explicit enum (we could "hide it" by using saturating_sub).

[MichaReiser]

There was actually a bug that we called increment twice in some cases. I refactored the code a bit

[dhruvmanila]

Thanks!