Responsiveness tweaks

[towerofnix]

This PR (if not technically, then spiritually) follows up #348 to try some smarter, subtle ways at keeping responsiveness good across screen dimensions and particularly long content.

Changes to the nav bar:

• General refactor for nav-link divider CSS - no substantive changes here. (This was supporting a metatag('blockwrap') use which turned out not to be useful. It's left since it simplifies a bit of the CSS, though it's debatable if the JS should be responsible for adding that .has-divider class or not...)
• Style nav-links as display: 'inline-block', ensuring words always remain together. This is not the same as using a blockwrap, because later nav-links are sibling inline-blocks (not descending ones). This basically means that if a nav link, on its own, takes up two lines then it occupies the entirety of those two lines, kicking the next link or content below. This doesn't often have an effect, but can make the nav layout feel more stable.
• The previous behavior of placing album nav links (gallery/commentary/random) as the last nav link's accent, and track nav links (previous/next/random) as navBottomRowContent, is unchanged. This is taken as a deliberate decision of the past which we try to uphold — allowing single-line navigation when an album name is sufficiently short or there aren't many "extra" links (gallery/commentary), but always placing track nav on its own row, to improve stability between track pages.
• However, the display: inline-block on sibling nav links means the accent of a nav link is now kicked down a row, if its main content (i.e. the link itself) is split across multiple lines. This is a notable improvement in stability for album pages, because previously the accent would just come after the last wrapped word; because the position of the split depends on the width of the screen, so too would the position of the accent. This meant nav links were arbitrarily horizontally shifting based on screen dimensions, which was a serious instance of resizing instability. Now the accent is always either aligned at the end of the full link, such that both the entire accent and the entire link are visible on one line; or beneath the nav link, aligned left with the start of the nav bar.
• One point of instability remains - it's possible (though rare) for the last nav link and its accent to be kicked to the second row, but thereafter have enough room to coexist on that row. In principle this is OK, but in practice there's usually an extremely narrow allowing window (if one at all), and just a little thinner will kick the accent onto its own line. As far as we can tell it's non-trivial, possibly impossible, to detect (without JavaScript) an inline-block having been kicked to its own line and then adapt it (or its following sibling) to be display: block, ensuring it's alone on its own line.
• In the thin layout, nav link accents are now always kicked to the line below the last nav link - if the nav bar has chronology links / content. This is to go for an all-vertical layout with the more complex appearance, but stay compact if it's simpler, and to improve resizing stability (the accent is usually naturally kicked down by word wrapping when approaching thin layout, if it's only allowed to occupy ~45% the total nav width).
• A "bug" is fixed with how html.isBlank() works, essentially redefining the function to be more in line with its actual usage — checking if the content in question would be displayed as nothing on the page. Since rendering as an actual toString() is expensive (and that's how [html.onlyIfChildren] worked), this now performs a relatively lazy search for non-empty string (or non-string primitive) content. The algorithm tries to avoid entering templates, since those involve computing a generate() function non-statically, but will do so if it can't find any other non-blank content (elsewhere in the immediately available tree).

Changes to other content:

• The sticky heading's actual title text now gets padding-right: 20px in non-thin layout, keeping it from being literally overshadowed by the floating cover art; in thin layout it's still 10px, sufficient to separate from the small sticky cover art.
• The maximum width for the "by Artists..." inline artist list (in track lists) is now 600px, like other content. Track names themselves can span the full width of the content area, but not artist names. See below.