Logging configuration handling in mandrel.bootstrap

mandrel.bootstrap:
* DEFAULT_LOGGING_CALLBACK set to a callable to invoke when
  no logging configuration can be found; callback should enforce
  a reasonable default.  Defaults to...
* initialize_simple_logging() does bare-bones configuration of
  logging for logging to sys.stderr
* find_logging_configuration() finds the logging configuration file
  within search paths, or throws an UnknownConfigurationException.
* configure_logging() sets up logging, using the configuration file
  if one is found or the DEFAULT_LOGGING_CALLBACK otherwise.
* get_logger() ensures that logging is configured and then attempts
  to retrieve a Logger from the logging subsystem.

This integrates logging configuration and logger retrieval into
our bootstrapper mechanism.

To-do: integrate this into Configuration class so configurable
things get a logger easily as well.
Support for logger retrieval from Configuration

Added a get_logger() method to mandrel.config.Configuration,
which uses mandrel.bootstrap.get_logger in conjunction with
Configuration.NAME to get the right logger object.

Explicitly decided against storing logging objects in the
Configuration instances, as this is something that needs to
be sorted out in a case-by-case basis.
Add flag for controlling disabling of existing loggers

If you're starting a project with mandrel, you may move forward
confident in the idea that logging is configured once.

However, if you're adding it to an existing project, you may not
have such confidence.  In such cases, you may want to allow
the logging configuration to coexist with legacy uses of logging.

The mandrel.bootstrap.DISABLE_EXISTING_LOGGERS flag controls
how the "disable_existing_loggers" keyword param is handled when
applying the logging configuration file.  While it defaults to
True, consistent with logging.config.fileConfig's default,
you can override the flag in your bootstrap file and therefore
allow multiple logging configs to coexist.

It happens that this was necessary for the integration test
module I'm about to submit.
End-to-end test

mandrel.test.integration_test exercises a bit of everything,
with no mocking:
* bootstrap file affecting search paths and logging config
* mandrel.config.Configuration subclasses proper retrieval
  of config and logger
* proper searching/prioritization of configuration files in
  a simple hierarchy.

This could get built out much more, but for now it suffices.
Expand README and improve formatting
ForgivingConfiguration, config docs, etc.

mandrel.config:
* Now the docs are a little better and more comprehensive
* ForgivingConfiguration class extends Configuration but defaults
  configuration to empty dict when no config can be found.

This should make it a lot easier to build out configuration classes
that have decent default behavior.
Added PyYAML dependency
python 2.6/2.7 unittest compatability issues

python2.6 unittest.TestCase issues:
* doesn't have assertIs; replaced with lame implementation in
  custom mandrel.test.utils.TestCase subclass.
* doesn't have context manager support for assertRaises; revised as
  standard invocation with a callable as the second argument.
Adjust gitignore to allow for a local tmp dir
Setup adjustments in prep for egg release

setup.cfg defaults tag to "dev" for the master branch.  Can
make the real releases happen on a release branch.

setup.py adds some more information to the proceedings.
Setup tweaks for initial release

Tweak build tag to -2, working through some initial build issues.

Removed data_file dependencies as they're giving problems with
the source distribution; move part of README and all of LICENSE into
the long description.
Merge branch 'release'

Note that setup.cfg change was overridden in the
merge to keep the build tag on "dev".
Utilities for python-name-to-actual-object conversions.

mandrel.util:
* get_by_fqn(name): given a fully qualified name, returns the
  underlying object (dynamically loading as necessary)
* class_to_fqn(cls): given a class object, returns the fully
  qualified name for that class.
* object_to_fqn(obj): given an obj, returns the fully qualified
  name for its class.

These will be helpful for things like runner utilities, but
also for Configuration class helpers (if you want a particular
configurable attribute to be a class name under the hood but an
actual class object in python space).
AbstractRunner class for basic bootstrapping runners

mandrel.runner.AbstractRunner:
* Doesn't actually run anything.
* Gives hooks to affect the bootstrapper from the command line
  via various options.
* Provides a standard set of options and corresponding callbacks
  that we can share amongst concrete runners.

To-do:
* callable runner
* script runner
Callable and script runner classes

mandrel.runner:
* CallableRunner: treats target as a fully-qualified name for a
  callable; loads it up and invokes it with remaining positional
  params.
* ScriptRunner: treats target as a path; puts remaining positionals
  on sys.argv for regular option parsing, and executes the specified
  path.

  Note that ScriptRunner prepares a global environment that sets
  __name__ to "__main__" (as if your script were the primary
  entry point) and __file__ to the script itself.
Provide runner scripts via entry-points mechanism

Installing the distribution will provide a couple
scripts that hook into the runners:
* mandrel-runner --> mandrel.runner.CallableRunner
  via launch_callable
* mandrel-script --> mandrel.runner.ScriptRunner
  via launch_script
Merge branch 'runners'
Logging and documentation improvements

mandrel.bootstrap:
* Made default logging case more flexible for configuration
* Increased information and readability of default logging format
* Documented most of the critical procedures and functions.
Fix __setattr__ / descriptor bug in Configuration class

See: https://github.com/ethanrowe/python-mandrel/issues/4

Fixed by detecting descriptor in __setattr__ and letting it
drive in this case, using suggestion outlined here:
http://feldboris.alwaysdata.net/blog/custom-setattr-and-descriptors-be-careful.html
Rearrange mandrel.config to be a package

Original mandrel.config becomes mandrel.config.core.
- Updated unit tests to refer to mandrel.config.core instead of
  mandrel.config, for the most part.

Package imports a few public-facing features from
mandrel.config.core so the public interface is (largely)
maintained.

Added unit test for checking the imports and "exports" of
mandrel.config itself.