Make MB aware of iOS bot configs and get iOS working.

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 20 matching lines @@
 
 ### Command line
 
 It is structured as a single binary that supports a list of subcommands:
 
 * `mb gen -c linux_rel_bot //out/Release`
 * `mb analyze -m tryserver.chromium.linux -b linux_rel /tmp/input.json /tmp/output.json`
 
 ### Configurations
 
-`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.
+`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
+`//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.
 
 ### Handling the analyze step
 
 The interface to `mb analyze` is described in the
@@ skipping 367 matching lines @@
 * 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.