Content embedders as unique services

[Ben Goodger]

Today, there is no requirement that an embedder of content is a unique service. Far from it - the API and convention is that they extend the set of core services exposed by content by "overlaying" manifests describing the additional interfaces they expose on top of //content's.

This overlaying occurs in all process types - as there is a Content<Type>Client for each process type where embedders may expose additional interfaces.

Because there are not unique services, InterfaceRequests between various process types from embedder code are today routed through pipes set up by //content. 

Down the line, it's our intent that content/browser becomes a "navigation" service. In a world where we want services to have a well understood API surface, routing unknowable interface requests via any of our core services seems untenable.

The solution is to make content embedders be themselves unique services, with their own manifests & API surface. So instead of having only content_browser, whose API differs from one content embedder to another; we allow it to have a well known surface for all embedders, and in the case of chrome, a "chrome" service and a "chrome_renderer" (etc) service that expose their own sets of interfaces.

-Ben