Some changes to allow recipes and modules to live noncentrally

scripts/slave/README.recipes.md

 Recipes
 =======
 Recipes are a flexible way to specify How to Do Things, without knowing too much
 about those Things.
 
 
 Background
 ----------
 
 Chromium uses BuildBot for its builds.  It requires master restarts to change
@@ skipping 332 matching lines @@
 ```python
 for TARGET in ('Bob', 'DarthVader', 'Charlie'):
   for test_function in (super_tool, default_tool):
     yield TestCase(test_function(BasicSchema(TARGET)))
 ```
 
 Next, we get to the `config_ctx`. This is the 'context' for all the config
 items in this file, and will become the `CONFIG_CTX` for the entire module.
 Other modules may add into this config context (for example, they could have
 a `hello_config.py` file, which imports this config context like
-`from RECIPE_MODULES.hello import CONFIG_CTX`. This will be useful for
+`CONFIG_CTX = DEPS['hello'].CONFIG_CTX`. This will be useful for

[iannucci, 2015/05/05 23:35:58]

import DEPS
CONFIG_CTX = DEPS['hello'].CONFIG_CTX

[luqui, 2015/05/06 22:18:39]

Done.

 separation of concerns with the `set_config()` method.). The string format
 argument that `config_item_context` takes will be used to format the test case
 names and test expectation file names. Not terribly useful here, but it can be
 useful for making the test names more obvious in more complex cases.
 
 Finally we get to the config items themselves. A config item is a function
 decorated with the `config_ctx`, and takes a config blob as 'c'. The config item
 updates the config blob, perhaps conditionally. There are many features to
 `slave/recipe_config.py`. I would recommend reading the docstrings there
 for all the details.
@@ skipping 169 matching lines @@
 Where's the docs on `*.py`?
 --------------------------------------------
 Check the docstrings in `*.py`. `<trollface text="Problem?"/>`
 
 In addition, most recipe modules have an `example.py` file which exercises most
 of the code in the module for both test coverage and example purposes.
 
 If you want to know what keys a step dictionary can take, take a look at
 `common/annotator.py`.