Add a common mistake case for header-only classes in components build doc

docs/component_build.md

 # The Chrome Component Build
 
 ## Introduction
 
 Release builds are “static” builds which compile to one executable and
 zero-to-two shared libraries (depending on the platform). This is efficient at
 runtime, but can take a long time to link because so much code goes into a
 single binary.
 
 In a component build, many smaller shared libraries will be generated. This
@@ skipping 235 matching lines @@
 cases above where `_IMPLEMENTATION` is inappropriately defined or inappropriately
 undefined. Use GN visibility to make sure callers don’t screw up.
 
 ### Putting exported symbols in static libraries
 
 As discussed above, exported symbols should not be in static libraries because
 the object file might not be brought into the link. Even if it is brought in
 today, it might not be brought in due to completely unrelated changes in the
 future. The result will be undefined symbol errors from other components. Use
 source sets if your component is made up of more than one target.
+
+### Exporting a symbol that is not linked in your component

[brettw, 2017/02/09 21:58:44]

I think the confusion you ran into is specific to header implementations. I
think (hope?) other instances of not defining the implementation in your module
will be pretty obvious.

So I'd make this more direct:

### Exporting functions and classes implemented in headers

When you implement a symbol in a header the compiler will put that in every
necessary translation unit and the linker will pick one. If the symbol is never
referenced by code in the shared library it's supposed exported from, it will
never be instantiated and never exported. The result will be undefined external
symbol errors when linking. Exported symbols should be declared in a header but
always implemented in a .cc file.

+
+If an exported symbols is not linked as part of its own component then it is
+not exported by the generated shared library. Other components that expect to
+see this symbol are not be able to find it which results in an undefined symbol
+error:
+
+    some_file.obj : error LNK2001: unresolved external symbol <some definition>
+
+For example this can happen if you have a header-only class that is not used
+inside the module itself. A simple fix in this case is to define the symbol in
+its own .cpp file.