Revert of Update docs and command line flags for MB.

tools/mb/docs/design_spec.md

 # The MB (Meta-Build wrapper) design spec
 
 [TOC]
 
 ## Intro
 
 MB is intended to address two major aspects of the GYP -> GN transition
 for Chromium:
 
 1. "bot toggling" - make it so that we can easily flip a given bot
    back and forth between GN and GYP.
 
 2. "bot configuration" - provide a single source of truth for all of
    the different configurations (os/arch/`gyp_define` combinations) of
    Chromium that are supported.
 
 MB must handle at least the `gen` and `analyze` steps on the bots, i.e.,
 we need to wrap both the `gyp_chromium` invocation to generate the
 Ninja files, and the `analyze` step that takes a list of modified files
 and a list of targets to build and returns which targets are affected by
 the files.
 
-For more information on how to actually use MB, see
-[the user guide](user_guide.md).
-
 ## Design
 
 MB is intended to be as simple as possible, and to defer as much work as
 possible to GN or GYP. It should live as a very simple Python wrapper
 that offers little in the way of surprises.
 
 ### Command line
 
 It is structured as a single binary that supports a list of subcommands:
 
@@ skipping 82 matching lines @@
 
 Instead, we have one config per unique combination of flags only.
 
 In other words, rather than having `linux_rel_bot`, `win_rel_bot`, and
 `mac_rel_bot`, we just have `rel_bot`.
 
 This design allows us to determine easily all of the different sets
 of flags that we need to support, but *not* which flags are used on which
 host/target combinations.
 
-It may be that we should really track the latter. Doing so is just a
+It may be that we should really track the latter. Doing so is just a 
 config file change, however.
 
 ### Non-goals
 
 * MB is not intended to replace direct invocation of GN or GYP for
   complicated build scenarios (aka ChromeOS), where multiple flags need
   to be set to user-defined paths for specific toolchains (e.g., where
   ChromeOS needs to specify specific board types and compilers).
 
 * MB is not intended at this time to be something developers use frequently,
   or to add a lot of features to. We hope to be able to get rid of it once
   the GYP->GN migration is done, and so we should not add things for
   developers that can't easily be added to GN itself.
 
-* MB is not intended to replace the
+* MB is not intended to replace the 
   [CR tool](https://code.google.com/p/chromium/wiki/CRUserManual). Not
   only is it only intended to replace the gyp\_chromium part of `'gclient
   runhooks'`, it is not really meant as a developer-facing tool.
 
 ### Open issues
 
 * Some common flags (goma\_dir being the obvious one) may need to be
   specified via the user, and it's unclear how to integrate this with
   the concept of build\_configs.
-
+  
   Right now, MB has hard-coded support for a few flags (i.e., you can
   pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in
   the string before calling out to the tool. We may want to generalize
   this to a common key/value approach (perhaps then meeting the
   ChromeOS non-goal, above), or we may want to keep this very strictly
   limited for simplicity.