This moves the search field up before the navigation. It's quite
commmon that search is near the top of the page. Also, this
results in a fixed position, because navigation is page dependent
and may be long, which could move the search field far down or
even off-page in the old layout.

The searchfield component
(sphinx-doc/sphinx#11045)
is more compact and does not have a heading, which reduces
clutter and gives more focus to the content sections.

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>

The changes in bb5dbf and 585c08 to clear the bottom border
are immediately getting overridden by the styles right below.
Swap the order so these styles are applied as intended.

Co-authored-by: jab <jab@users.noreply.github.com>

Alabaster does not need to adapt the width. Geometry is handled by the basic theme.
In fact, this could cause wrapping of the search button for some magnifications.

As well as fixing the case for the default `theme_page_width`, it works with customised values too (which was my main motivation for this!)

Analysis/explanation:

- The issue was a  `max-width: 875px` block that came after a `max-width: 870px` block.

- If you are below 875px but not 870px, then you get properties from 875 block only. This gives a very strange 5 pixel window for certain changes, which must be a mistake.

- Some properties were defined in both 875 and 870 block, and were pointless because these are always overridden by 875 (since if you are below 870 you are always below 875, and the 875 block comes second in the source).

- So I've combined all these into one block, keeping the 875 blocks values where they differ. In many cases there was just duplication which I removed.

- I changed the breakpoint width to `{{ theme_page_width }}`, which gives (almost) the correct behaviour. There is still a slight clipping issue, which is caused by the width of the scrollbar, and the way that browsers include that in width calculations - an issue which, after a lot of Googling, doesn't appear to have any nice solutions. One way would be to just add, say, 20px to  `theme_page_width` but this is not convenient for us to do, since the value we have has units. So for now, I'd recommend just living with this small glitch - it is barely noticeable, and due to margins the page switches layout before any main text is obscured.

- I've fixed the sidebar breakpoint similarly for `fixed_sidebar` option. This was at a `min-width: 876px` breakpoint. Since we can't do 1px adjustment calculations (as above), I inverted the logic, creating an additional section in the `max-width: {{ theme_page_width }}` block instead. I've tested and this seems to work fine.

Co-authored-by: introt <introt@koti.fimnet.fi>