Adding a separate `keepText` field for the `updateBrew()` API might be a bandaid for something that should be looked at more deeply as a separate refactor, considering `updateBrew()` is configured to just return the stub and not the whole document.
For now, re-scanning for script tags after updating can be as simple as just re-looking up the brew.
Making some changes to the reset.less so that some default UA button styling is removed.
Then, changing core.less so that the classic "HB" button styling is scoped to a certain class `.colorButton`. This will make it easier to use the button element in other places.
When the page is zoomed in very close, such that <30% of the page is in view, it doesn't register changes to the 'current page'. This fixes that, passing in the 'centerPage' if 'visiblePages' is empty.
I don't love this fix, i think the visiblePages should always have *something* in it, but I can't quite figure out how to set that (since the normal update to visiblePages is happening in an observer that doesn't fire if nothing is in view).
the `safe` keyword for `justify-content`, in combo with `center`, means that the content will be centered in the viewport unless there is not enough space for it. If there is not enough space, it aligns it to the *start*/left edge, rather than keeping it centered and clipping the left edge of the page.
The memoization of the renderPages() method prevents a re-render when something like pageShadows is updated, so displayOptions are added to the dependency array in the memo method.
Prior to fix, the "next page" button in the toolbar wouldn't work well if there were multiple pages in view that were in a single 'row'. This is because the logic is to take the pages that are "visible", take the max of those pages, and then scroll to that page. But the issue is that if the 'max' page is in the same row as other pages, the range of visible pages doesn't change....the max will always be the same.
So the change here basically runs the scroll function twice-- if the first run results in the same 'max' page as before the scroll, it runs it again but with the target page being "max + 1", which will bump the target to the next row.
