Use real URL parsing for links found in messages, particularly to narrows

This is a piece of #4146.

We have a small pile of code which processes URLs and is ultimately all called on URLs found in messages the user interacts with:

• all of src/utils/internalLink.js, which is exclusively invoked from messageLinkPress, where we parse a link the user has selected in a message and decide, in particular, whether it's a link to another chat narrow and if so how to navigate to that narrow;
• isUrlOnRealm in src/utils/url.js, which is called from internalLinks.js and one other spot, the lightbox, where the URL ultimately comes via navigateToLightbox from an image or link the user has selected in a message.

This code contains some pretty messy ad-hoc string processing of the URL, and we should replace it with real URL parsing with new URL.

In particular, several spots in this code potentially changed behavior with #4235, where we started using a realm URL object with realm.toString() (which will look like https://chat.example/, with trailing slash) in places where we'd previously used a realm string (which we'd normalized to lack a trailing slash, like https://chat.example). I noticed this following #4290, which was a serious regression caused by a similar change. I think there are no meaningful regressions from these -- I think the behavior changes happen only with odd-looking URLs like https://chat.example#narrow/stream/123-name, with a missing slash, which the webapp doesn't generate and users are unlikely to send -- but I'm not sure of that, partly because the existing behavior was so messy in the first place.

Specifically, the following sites changed:

• getPathsFromUrl, in internalLink.js
• isInternalLink, in internalLink.js
• isUrlOnRealm, in url.js

Each of them should switch to using URL objects, and their properties like .hash and .origin, to do its job.