Feature: Bake in searchId and url in searches

[SEMilfred]

Backend has a list of properties they use from our searches.

Most of these are always added (or at least, when needed) through our search fields, like text, siteId, and cultureId/culture, whereas url, pageId and searchId are not.

searchId
searchId should be a GUID we generate from the frontend, and as we generate it from the frontend we might as well bake it into LimboSearch as well.
We might need to figure out the exact extend of when a new searchId is generated, but generally a new search = new id (ie., more results of the same search is not a new id).

"As an example, if the user searches for hello, and then chooses to load more results, both requests to the search API should have the same value for the searchId parameter. If the user then searches for hi afterwords, a new GUID should be generated and sent along to the search API. If the user changes the search text back to hello, a new GUID different from the first one should be sent to the search API." (from the backend analytics link)

Others
We need to write documentation (and figuring out a setup) for the necessary properties for search in general and for making analytics work.
This should be in the package docs.

To make sure analytics work, its important with the searchId (which will be handled in the above) and both pageId and url. If the search is an overlay these will be for the current page, but usually the search is a standalone page in which case the pageId and url should be the page leading into the search (ie. where did the searcher come from?).