[mojo-doc] Add note about in-process messaging

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed.
 
 [TOC]
 
 ## Should I Bother Reading This?
 
 If you're planning to build a Chromium feature that needs IPC and you aren't
@@ skipping 163 matching lines @@
 
 // Tada!
 frobinator->Frobinate();
 ```
 
 Behind the scenes this serializes a message corresponding to the `Frobinate`
 request and writes it to one end of the pipe. Eventually (and incidentally,
 very soon after), `impl`'s internal `mojo::Binding` will decode this message and
 dispatch a call to `impl.Frobinate()`.
 
+**NOTE:** In this example the service and client are in the same process, and
+this works just fine. If they were in different processes (see the example below
+in [Exposing Services in Chromium](#Exposing-Services-in-Chromium)), the call
+to `Frobinate()` would look exactly the same!
+
 ### Responding to Requests
 
 A common idiom in Chromium IPC is to keep track of IPC requests with some kind
 of opaque identifier (i.e. an integer *request ID*) so that you can later
 respond to a specific request using some nominally related message in the other
 direction.
 
 This is baked into mojom interface definitions. We can extend our `Frobinator`
 service like so:
 
@@ skipping 135 matching lines @@
 
 This is a work in progress. TL;DR: We'll also soon begin using Mojo services
 from Blink so that the platform layer can consume browser services
 directly via Mojo. The long-term goal there is to eliminate `content/renderer`.
 
 ## Questions, Discussion, etc.
 
 A good place to find highly concentrated doses of people who know and care
 about Mojo in Chromium would be the [chromium-mojo](https://goo.gl/A4ebWB)
 mailing list[.](https://goo.gl/L70ihQ)