JS: Add ClientSideRemoteFlowSource

[asgerf]

Makes window.location-based sources part of RemoteFlowSource by introducing ClientSideRemoteFlowSource, with a getKind() predicate indicating it is (part of) the URL, path, query, fragment, or window name. (see qldoc for full details)

It's meant to address a few issues

1. Using RemoteFlowSource is now a reasonable default taint source for a new query; we don't have to teach users about DOM::locationRef() as well.
2. The framework models for Angular/React router contributed some remote flow sources for parameters extracted from the path. RemoteFlowSource thus contained some, but not all, client-side URL sources, which was a bit inconsistent.
3. For some queries we want to treat sources based on the path differently, because they cannot contain ../ sequences (the browser normalizes the path). In particular, request forgery has some FPs where the source is from the path. This PR disables that particular source for request forgery.

There are a few downsides to this approach:

• new URL(window.location) is not modelled very precisely.
• Queries that aren't interested in client-side URL sources should now explicitly opt out, and there isn't a particularly pretty way to do so. We could add something like ServerSideRemoteFlowSource but a truly good name for that class eludes me as we can't generally ensure that a given source occurs in a server (e.g. it could be in a library shared between client and server, or it could just be a CLI app that's not a web server).

Evaluation:

• Code scanning queries on default slugs looks good

[asgerf]

Evaluation finally looks good 🎉

[erik-krogh]

LGTM.

Just a comment about helper predicates on RemoteFlowSource.