Improve `Modal.FooterButtons` API

[TyMick]

Part of FLCOM-8106.

Implements the more flexible Modal.FooterButtons API discussed in this Styled UI Flowdock thread and deprecates the old commitButton, cancelButton, and deleteButton props in favor of it.

A summary of the API change:

• Before

  <Modal.Footer>
  <Modal.FooterButtons
    commitButton={{ text: 'Save', onClick: () => alert('Saved') }}
    cancelButton={{ text: 'Cancel', onClick: () => setState({ modal: !state.modal }) }}
    deleteButton={{ text: 'Delete Forever', onClick: () => alert('Deleted') }}
  />
  </Modal.Footer>

• After

  <Modal.Footer>
  <Modal.FooterButtons>
    <Modal.FooterButton variant="primary" onClick={() => alert('Saved')}>
      Save
    </Modal.FooterButton>
    <Modal.FooterButton variant="secondary" onClick={() => setState({ modal: !state.modal })}>
      Cancel
    </Modal.FooterButton>
    <Modal.FooterButton
      variant="danger"
      onClick={() => alert('Deleted')}
      marginInlineEnd="auto"
    >
      Delete Forever
    </Modal.FooterButton>
  </Modal.FooterButtons>
  </Modal.Footer>

024fc0993b0b8a4cadf04566d246d6a7338debbf is actually the only fix I originally needed for FLCOM-8106, but I think I'll use the new API for that case anyway, since I like it better. 🥳

Important review points

I'd recommend walking through this PR one commit at a time when reviewing. Each step is pretty atomic.

• Was 3f8bce08ff027cc860d6271710a33b58ed14a755 a good decision? Removing the element measuring will make the component much more maintainable, and the useFullWidthButtons behavior was only triggering on screens less than 320 CSS pixels wide, so these full-width buttons wouldn't even be used on an iPhone 5/SE. If a dev is expecting buttons to have enough text that they need to think about making the buttons full-width, they should probably build their own special handling.

• Once I refactored in a4b2529 to use the gap property (which is safe to use now that it's been added to iOS Safari), moving a third button to the left side on its own became as easy as adding marginInlineEnd="auto" (the language-direction-agnostic alternative to marginRight="auto") to it. We'd discussed making Modal.FooterButtons automatically shove the last child button to the left if there are at least three, but if the CSS is this easy, is requiring the dev to enter it a fine alternative? This would also allow for different groupings of buttons (say, two buttons on each side).

[korbinancell]

requiring the dev to enter it

What do you think of adding a floatLeft or alignLeft prop that applies this css?

[TyMick]

Maybe floatAcross (or floatOpposite) since I switched the right/left properties to logical properties?

[TyMick]

I've gone with floatAcross for now. (And edited past commits to do so, to keep the commits organized—sorry if that throws off anyone's review.)

[TyMick]

Rebasing to pull in #530 (to make it easier to yalc publish).

[PatrickNausha]

Was https://github.com/Faithlife/styled-ui/commit/3f8bce08ff027cc860d6271710a33b58ed14a755 a good decision? Removing the element measuring will make the component much more maintainable, and the useFullWidthButtons behavior was only triggering on screens less than 320 CSS pixels wide, so these full-width buttons wouldn't even be used on an iPhone 5/SE.

This logic seems sound to me. If useFullWidthButtons is never true in practice, the code seems effectively dead. In theory a consumer could make a modal as narrow as they want, shrinking it below 320px, but I'm not sure why they would.

[TyMick]

Thanks so much for the review, @PatrickNausha! Would you like to take one more pass before I merge?

[PatrickNausha]

I just saw the documentation page for the first time. Should Modal.FooterButton be on that page?

[TyMick]

Ready for another pass, @PatrickNausha; thanks again!