Implement multi-phase build support in 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
@@ skipping 28 matching lines @@
 ### Configurations
 
 `mb` will first look for a bot config file in a set of different locations
 (initially just in //ios/build/bots). Bot config files are JSON files that
 contain keys for 'GYP_DEFINES' (a list of strings that will be joined together
 with spaces and passed to GYP, or a dict that will be similarly converted),
 'gn_args' (a list of strings that will be joined together), and an
 'mb_type' field that says whether to use GN or GYP. Bot config files
 require the full list of settings to be given explicitly.
 
-If no mathcing bot config file is found, `mb` looks in the
+If no matching bot config file is found, `mb` looks in the
 `//tools/mb/mb_config.pyl` config file to determine whether to use GYP or GN
 for a particular build directory, and what set of flags (`GYP_DEFINES` or `gn
 args`) to use.
 
 A config can either be specified directly (useful for testing) or by specifying
 the master name and builder name (useful on the bots so that they do not need
 to specify a config directly and can be hidden from the details).
 
 See the [user guide](user_guide.md#mb_config.pyl) for details.
 
@@ skipping 357 matching lines @@
 
 * 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
   [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.