Develop better rule for stubborn-merging p1 operators

[tconbeer]

Describe the bug
Today we stubborn (or partially) merge a segment that starts with a p1 operator onto a prior segment according to this rule:

sqlfmt/src/sqlfmt/merger.py

Lines 316 to 325 in 8ee52b1

	# stubbornly merge p1 operators only if they do NOT
	# follow another p1 operator AND they open brackets
	# and cover multiple lines
	or (
	not prev_operator
	and self._segment_continues_operator_sequence(
	segment, min_priority=1
	)
	and self._tail_closes_head(segment)
	)

But there are edge cases where that is bad, like:
https://github.com/tconbeer/rittman_ra_data_warehouse/blob/e65dd4a8020c912a98cc87fb722055ea7c72be79/models/sources/stg_hubspot_crm/bigquery/stitch/stg_hubspot_crm_deals.sql#L233-L241

Part of the problem is that we compute prev_operator after the previous segment may have had some merging.

But the other part of the problem is that the "covers multiple lines" test doesn't try to merge the current segment first, so we end up with things like:
https://github.com/tconbeer/rittman_ra_data_warehouse/blob/e65dd4a8020c912a98cc87fb722055ea7c72be79/models/warehouse/w_marketing/wh_attribution_fact.sql#L117-L118

A better rule would be more consistent and predictable. It may rely on changing the subbornly_merge implementation to try different merging tactics with different operators (#211)