consider exposing self.clients on window and other worker globals

The Clients and Client interfaces are pretty close to being a generic API for querying and manipulating windows/workers in the browser. Its nicer than things like window.open() though because its designed to be async and is less permissive in what the caller can do.

I think we should consider exposing Clients and Client interfaces on windows and other worker globals. Perhaps as navigator.clients to avoid name collisions.

To do this we would need to specialize the interface for service workers a bit, though:

1. Clients.claim() does not make sense outside of a service worker global.
2. Client.postMessage() currently goes to navigator.serviceWorker.onmessage. This would need to still happen for service worker globals. When used from other globals we would need to fire the event at a different target. Perhaps navigator.clients.onmessage.
3. The behavior of clients.matchAll() only returning controlled Client objects only makes sense for service worker globals. Other globals should probably imply includeUncontrolled:true.

All same-origin restrictions would still apply. I assume we would only support this in secure contexts.

If we think we might want to do this it would be nice to do it sooner rather than later. Over time we will probably have more service worker specific features creep into the API.

Start by reviewing the existing Clients and Client interfaces and the service-worker-specific behavior described in the issue. Compare navigator.clients exposure, Clients.claim(), Client.postMessage(), and clients.matchAll() across window and worker globals. Done means the supported globals, event targets, control rules, and secure-context restrictions are specified.