Brings over the tabs component along with the same URL parameter behavior from the BatchChangeDetailsPage, but this time presenting only "Changesets" and "Spec" tabs as options.
I noticed the pre-existing component a) hardcoded the 4 tab panels it would render (since it was only being used in that one place) and b) implemented its tabs/panels manually. In order to share code between the detail page and the preview page without writing a new spin-off of the existing tabs or introducing an unhealthy number of new props, I refactored BatchChangeTabs to better support composition, so that each page could decide for itself what sort of tabs to render. The refactor also takes advantage of the ReachUI tabs components, which automatically handle all of the tab panel state and accessibility concerns, as we were already using them elsewhere in the codebase. This cut out a huge amount of boilerplate from the BatchChangeTabs component!
The end result is a series of smaller, more flexible and reusable building blocks for tabs that can be composed with the following natural, hierarchical API:
This allowed me to easily reconstruct the 4 tabs for BatchChangeDetailsPage, giving the control of the tabs back to the parent page at the same time, and then build a new two-tab set for BatchChangePreviewPage from the same pieces!
