Add ability to pass objects from test_description to tests

[pbaughman]

Description

To facilitate writing test factories (and to clean up the module scope of tests a little bit), we need a way to pass information from the generate_test_description function over to the tests. Previously you could do this by declaring things at the module level but that's a little gross, and it doesn't make it very easy to write a factory class that makes test descriptions and automatically makes the corresponding tests that go along with.

To make this cleaner, the generate_test_description function can optionally return a second object - a dictionary. Each item in the dictionary will be injected into the individual tests as though the object was an attribute with the same name as the dictionary key. Each item in the dictionary will be passed to the individual test cases if they're declared with an argument with the same name.

This will let us write factory methods that return a complicated launch descriptions and pass parts of the complicated launch description transparently to factory tests.

Notes for Reviewers

I left good_proc.test.py the way it was because the examples are also test cases, and I want to make sure we don't regress the case where a test description only returns one object

example_test_context.test.py shows the new functionality, and has some simple tests that use the launch context

Todo:

• _bind_test_context_to_tests should make sure the attribute name doesn't already exist so we're not overwriting important test functionality. This should probably be an error
• [x] Merge https://github.com/ApexAI/apex_rostest/pull/22 and rebase this branch, then change the PR to target master

[pbaughman]

@hidmic This kind of does what you were talking about in https://github.com/ApexAI/apex_rostest/issues/20 but doesn't get you the launch context. It will reduce the amount of stuff that lives at the module level scope, though.

[pbaughman]

@hidmic Ok, what about this? We can partially bind arguments to the test methods before we pass them to the runner. I had to touch some underbar variables in unittest.TestCase to do it, but YOLO. Bad stuff will happen if someone adds something to the test context named 'self' but like my doctor says "if it hurts when you do that, don't do that"

[hidmic]

@wjwwood mind to take a look too?

Also, for some reason I don't have full reviewer powers here.

[pbaughman]

@hidmic Fixed your lack of review powers. We missed you somehow when we added William