Implement `scaleanchor` domain constraints on matching axes

[etpinard]

follow-up issue from #3506 where matches and scaleanchor constraints on the same axes are disallowed.

Pasting some of @alexcjohnson 's comment on the topic here:

---

#3506 (comment)

yeah, that one has some problems... looks like after a zoom/pan it manages to satisfy all the constraints (the very shrunken subplots I think are correct), but initially or after an autorange it does not.

Here's a more extreme example. Kind of a pathological case, where each subplot has x&y matching, and the x of each subplot is supposed to scale with the y of the previous... this is the case I think compounds height/width differences, so it should be expected that either the first or last subplot gets its data very compressed if you stretch it to a very non-square size. Right now it appears to apply all the scaleanchor constraints, but all the matches constraints except the last are lost.

Plotly.newPlot(gd,[
  {y:[1,2]},
  {y:[1,2],xaxis:'x2',yaxis:'y2'},
  {y:[1,2],xaxis:'x3',yaxis:'y3'},
  {y:[1,2],xaxis:'x4',yaxis:'y4'}
], {
  yaxis: {matches: 'x'},
  xaxis2: {scaleanchor: 'y'},
  yaxis2: {matches: 'x2'},
  xaxis3: {scaleanchor: 'y2'},
  yaxis3: {matches: 'x3'},
  xaxis4: {scaleanchor: 'y3'},
  yaxis4: {matches: 'x4'},
  grid: {rows: 2, columns: 2, pattern: 'independent'},
  width: 500,
  height: 400
})

I haven't looked at your code in detail yet, but in order to satisfy this kind of chained constraints seems to me it may be necessary to generate scaleanchor constraints based on each matches constraint (using gs._w and gs._h) and use that to run through the scaleanchor algorithm, and only after that apply the matches constraints explicitly.

---

From a private slack convo:

also re: matches and scaleanchor constraints with different target axes - the mock I set up has two separate constraints on each axis (except the ends of the chain). My comment “the only allowed values of scaleanchor would be ‘x’ or nothing.” was about a single constraint, ie the constraint defined within one axis’s attributes. If you’ve already said yaxis.matches: 'x'it wouldn’t make sense to say yaxis.scaleanchor: 'x2' because that would be setting up a completely different constraint. But it should still be OK to say xaxis2.scaleanchor: 'y'. After you’ve already provided matches it seemed to me the only purpose of scaleanchor is “do you also want to constrain the scale along with the matching constraint”

[emmanuelle]

Mentioned in the community forum https://community.plotly.com/t/synchronizing-view-zoom-of-several-images/39661

[nicolaskruchten]

So we did initially implement support for both of these at once, and it was removed in this commit 91431ec due to the discussion above.

For the specific case of faceted images i.e. plotly/plotly.py#2746 however, it seems like the original implementation would have worked just fine, so if we could roll back that commit and re-implement the "dropping" of scaleanchor less blindly, we might be able to get the kinds of scale constraints that px.imshow wants to work well with matches.

Specifically, it seems to me that so long as there is no chain of matches that mixes up x-axes and y-axes (i.e. that any x-axis only matches and is matched by other x-axes and vice versa) and that no chain of scaleanchors binds any x-axis to any other x-axis or vice versa, then none of the very-pathological behaviour described above will happen.