"Global search" example seems outdated

The [`api-samples/contextMenus/global_context_search` example](https://github.com/GoogleChrome/chrome-extensions-samples/tree/main/api-samples/contextMenus/global_context_search) describes itself as, "letting a user switch between searching different countries' versions of Google", but that's no longer something that Google supports. While it's still possible to perform a regional Google search (see below), switching the domain for the request isn't how.

* I _**get**_ that it's just an example.
* I _**get**_ that different search URLs **ARE** still generated based on the user's selections.
* I _**get**_ that it's still an effective demonstration of the `contextMenus` APIs that it's _meant_ to be demonstrating.

But, it's not really a great example anymore. The best examples demonstrate how to do something trivial but **useful**, letting the user experience _why_ these APIs exist and would be of interest to developers.

And because Google has globalized its service offerings, beyond the string displayed in the URL bar there is no longer any visible difference loading any of these URLs:

* https://www.google.ca/search?q=my+search
* https://www.google.co.jp/search?q=my+search
* https://www.google.ru/search?q=my+search

(They used to be different, long ago. I assume they still were, when the example was originally written. But no longer.)

In all cases today, Google will show the exact same search results, localized based on an approximate geolocation derived from the requesting IP address. Which makes the example seem pointless.

Perhaps a more current example would be useful. Like:

* Setting a Region parameter for the search. (`&cr=countryCA` vs. `&cr=countryJP` vs. `&cr=countryRU` etc.) That _will_ have the effect that switching the TLD _used_ to have. (Although the results will still be in the user's presumed language, unless a corresponding `&lr=lang_en` / `&lr=lang_jp` / `&lr=lang_ru` / etc. parameter is also set.)
* Switching between different Google search categories via the `&udm=` parameter, though as that's largely undocumented (from official sources, at least) it may not be the best or more future-proof choice.
* Something else entirely?