XKit Preferences: Vertical nav layout menu button fix

[marcustyphoon]

The logic I implemented in #2109 is fragile: in the vertical nav layout, it appends the XKit menu button after the last navItem element, which is currently the "get a domain" button. If this is removed, however, the last navItem element will be nested inside the account drawer, which is obviously bad.

This implements* the same logic as ${keyToCss('drawerContent')} ${keyToCss('navigationLinks')} > ${keyToCss('navItem', 'subNav')} from https://github.com/AprilSylph/XKit-Rewritten/pull/1107: it finds the element which contains the top level of navigation and inserts the XKit control button after the last of its children which is either a navigation item or the menu that one opens.

This should ensure that the XKit control button is a) at the top level, not nested somewhere wild, and b) after other nav items but before things like the frogs, bells, crabs, whatever.

*manually, since :is() requires chromium 88 and I have no idea what our browser support list is supposed to be

[marcustyphoon]

(This does not currently contain a version bump to xkit_preferences.js)

[AprilSylph]

The last reliable item in the navigation is now TumblrMart, which has a structure unique to popover-capable nav items.

The "Get a domain" and "Go Ad-Free" items are ephemeral and disappear as soon as a purchase is made.

[marcustyphoon]

Oh, targetPopoverWrapper. So this is currently broken then.

[AprilSylph]

I think targeting the parent (assuming it can be targeted uniquely) and inserting the button into it as the last child is probably the most reliable approach.

[marcustyphoon]

That would be easy, I think. I was trying to put it before the bells button back when that was a thing; I can't be bothered to buy myself crabs or whatever to see what that UI looks like and whether it looks more natural to precede that, but I assume it would.

Edit: Yeah, to no one's surprise, this looks very silly: