Details redesign tweaks and refactoring

[DingDongSoLong4]

These are a few tweaks and changes related to the recent details redesign, with some refactoring thrown in as well.

• The state flag for the sticky header is now initialized to the correct value rather than waiting for an onscroll event. This fixes an issue I came across where the sticky header would flicker if the page's initial scroll position was such that the header should show.
• The intl ID for the StashID detail item label was incorrect, leading to a console error and the ID being directly displayed (ie without being translated). I've fixed this and also added i18n for a few other hardcoded "StashIDs" labels. This does bring up the question on whether it's "Stash IDs" or "StashIDs" - the en-GB.json translation file has "Stash IDs" but the hardcoded strings all were "StashIDs". All the labels are now consistently display "Stash IDs", but I feel like "StashIDs" looks better - although maybe that's simply because I've seen "StashIDs" more often.
• The main details redesign-related fix is removing the window.scrollTo(0, 0) in the GridCard onclick event and instead scrolling up to the top when a "long" component (studios, tags, etc pages, list pages) is mounted. The scrollTo in the onclick was causing the page to unconditionally scroll up when clicking on a card, even if the click doesn't actually navigate away to a new page (eg a middle click to open in a new tab).
• Added an id to the cover field of SlimGalleryData, thus allowing the field to be properly cached, which fixes a console warning complaining about the missing ID. I also set the merge function for the paths field of a Scene object to false, fixing another console warning, and removed a few unnecessary false merge functions on fields which return normalized objects and thus do not need them.
• Refactored the ugly page title string templating code out into useTitleProps and makeTitleProps, and made it more modular with support for multiple pipe-separated parts.
• Refactored the various loaders (SceneLoader, PerformerLoader, etc) and created an ImageLoader to directly use the RouteComponentProps passed to them by react-router instead of useLocation or useParams.
• Refactored the handling of the "tab" URL parameter, adding a TabKey type. Now instead of having /performer/11 display the performer's scenes, the page will be redirected to /performer/11/scenes first before showing the scenes. This allows for a possible future feature where you would be able to set the default tab instead of it being hardcoded. Existing URL query strings are retained by the redirection, retaining backwards-compatibility: /performers/1?sortby=date will redirect to /performers/1/scenes?sortby=date for example.
  Edit: This is now just a refactor of the tab handling - the behaviour should match how it was before. I'll leave that change for a subsequent PR implementing [Feature] Global settings option to set the default opened nav-tab (for Performer, Tag, Studio pages) #3961.
• And lastly, refactor to use classnames to generate the class string for the .detail-header instead of doing it manually with a template string - it just looks a bit cleaner.

This ended up being a lot bigger than I had anticipated, because I kept stumbling across things to refactor and couldn't help myself. I'm happy to split anything out into separate PRs if necessary.

[AdultSun]

For what it's worth, I've always thought of it as "StashIDs" as well. It feels like that's been the most commonly used spelling too, both within the UI and in conversation.

[cj12312021]

I didn't run into any issues with the changes during my testing. I suspect the URL changes you made will break a lot of user scripts, but they can be updated.

[cj12312021]

This makes sense. It wasn't this solution that it sunk it that useEffect's run on render.

[cj12312021]

I was actually under the impression that StashID wasn't meant to be translated. I didn't realize a location string existed for it.

[DingDongSoLong4]

I only noticed because I was getting a console error about a missing intl string - react-intl's behaviour of just showing the ID when no intl string exists isn't meant to actually be used, it's just a fallback so that at least something is shown.