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 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.