Removing broken stem.util.control import

I deleted stem/util/control.py but forgot to rm the pyc afterward so stem
continued to work for me despite having a broken import. Caught by Beck.
Fix #6248 and make test_get_pid_by_open_file cross-platform while doing so
Clarifying comments for the get_pid_by_open_file test

The prior fix is better for the test (working == better!), but makes it a bit
less self-descriptive. Adding a couple comments.
Skipping tests that make repeated connections on OSX

Stem's tests currently hang on Mac OSX, and that doesn't look to be getting
better any time soon...
https://trac.torproject.org/5917

I've narrowd this down to being either a python, tor, or mac bug with how
repeated socket connection/closures are handled on that platform. For now
skipping the tests that encounter this issue if we're running on a mac.
Accounting for logging.Handler bug in python 2.5

In python 2.5 logging.Handler doesn't extend object, causing our super() call
to fail with a stacktrace. Hacking around it.
Processing proc stat files with more than 44 entries

A long-standing arm and stem bug is that it checks if '/proc/<pid>/stat'
contains exactly 44 elements and, if not, refuses to parse it. This is a
mistake, stat files may have more entries depending on the platform. Changing
the check to account for this.
Skipping proc tests broken by tor's disabledebugger features

Stem's proc integ tests exercise that utility by running it against our tor
instance. However, as discussed in ticket #3313 the DisableDebuggerAttachment
feature screws up our proc permissions. Skipping those tests if they would fail
due to this.

Caught by Ravi in...
https://trac.torproject.org/6286
Replacing platform specific %D date formatting

Python's strftime() method has a set of platform independent flags, but also
accepts anything that our platform's libc does...
http://stackoverflow.com/questions/10807164/python-time-formatting-different-in-windows

I was using '%D' date formatting for our logging, but that doesn't work on
Windows...
https://trac.torproject.org/6206

Replacing with the equivilant platform independent flags. Issue caught by Beck.
Fix Controller.get_conf_map's documentation formatting
Add a generic SingleLineResponse class
Add set_conf wrapper method
Add unit tests for SingleLineResponse and add missing imports
Add SETCONF integration tests, SingleLineResponse unit tests and the bugfixes that come with them
Add Controller.reset_conf and fix Controller.set_conf
Make tests cross-platform & fix things that broke during a rebase
Fix documentation formatting
Make get_conf_map work properly with HiddenService* options
Revisions for prior SETCONF and RESETCONF additions

Several revisions to the prior changes, the most prominent of which is to use
an API more similar to arm's. The SETCONF and RESETCONF methods are
functionally identical except how they handle undefined values, so there's
little reason to provide separate methods in our controller. Just using an
optional 'reset' arg instead.

One thing that arm got wrong (and so did stem) is that our method to change
multiple options should accept a dict rather than a tuple list. Order *might*
matter for the accursed HiddenService options, but for the 99.9% use case a
tuple list is a very strange argument to accept for this.

This also includes some testing fixes, for instance...
* Testing when we have a list argument (for instance, setting our ExitPolicy).
* Failing our test if one of the calls that should fail actually succeeds.
* Reverting the configuration options that we change after the test.
* An identical test for context sensitive options was added to both the getconf
  and setconf test. Definitely a good use case to check and it could belong
  with either setconf or getconf, but doing the same test twice is pointless.
Reintroducing tuple support to get_options

Damn I hate it when I'm right. The reason that arm supported tuple lists is the
fucking HiddenService* options. Adding support for them back in, though I gotta
admit that I flirted with the idea of just saying "screw hidden services".
These things are such a hack...
Splitting set_conf/reset_conf back up

Ravi made a good point that the set_option() syntax for resetting config
options is now worse, so trying a compromise of our approaches.

This reintroduces set_conf() and reset_conf() methods, but also keeping my
set_options() method to handle the more complicated use cases (batch setconf
requests, resetconf with values, and context sensitive options).

Personally I found the old set_conf() method confusingly overloaded (python
does not handle overloading use cases very well). This solution lets us keep
the set_conf() and reset_conf() methods simple, while also providing something
that's reasonably intuitive (imho) for the complicated use cases.