Add new variables for url properties

[OkanEsen]

Wiki should be updated accordingly.

Here is the new list of variables for the wiki entry:

${hash} | Contains a `#` followed by the identifier.
${host} | Hostname followed by port (if it was specified)
${hostname} | Contains the domain
${href} | Contains the whole URL
${origin} | Origin of the URL (structure same as `${href}`)
${password} | Contains the password (if it was specified)
${pathname} | Contains the path
${port} | Contains only the port number (if it was specified)
${protocol} | Contains protocol scheme including `:`
${search} | Contains everything after `?`
${searchParams} | This returns an object containing all search params (if there are any). To access the parameters, you need to use the `getParams` filter.
${username} | Contains the username (if it was specified)

And for filters:

getParams | param | Returns specific parameter for given `searchParams`

[marklieberman]

I built on your PRs but extended the functionality quite a bit.

I added variables for item, frame, and tab URL. I figured it would be more useful to tag the files with domain.com, rather than like cdn1.domain.com, img.domain.com, etc.

I also extended the expression syntax so variables can take a parameter like: ${itemUrl[hostname]}, its a little more verbose but still easier than having 3 separate sets of URL parameters.

The searchParams are accessed with dot notation like so: ${itemUrl[search.q]} instead of having a filter to unpack them.

The cleanSplit function was replaced with a tokenizer that doesn't split regexes. The method you had of matching the known filters did work, but it had a side effect of not reporting an error when a filter was unknown.

I didn't realize the URL interface did parsing, so after seeing your PR I was able to replace some parsing logic with uses of URL.

[OkanEsen]

Oh yeah, for sure, I like your approach much better and replacing the cleanSplit function with a tokenizer is much better imo. Thanks for your hard work, appreciate it a lot!