Refactor: move execution logic out of resttest.py to allow for xUnit Output Callbacks

[svanoort]

Per https://github.com/svanoort/pyresttest/issues/163 this is in support of the xUnit changes

We are moving the test/benchmark execution logic into the macros themself:

• [x] Move config/response methods and parser methods into parsing.py or a new macros.py class, and tests
• [x] Move test execution logic into an execute method within the test, and invoke that for running
• [x] Move benchmark analysis methods into benchmark themself
• [x] Move benchmark execution logic into a benchmark execution method, and invoke that for running
• [x] Define callbacks and refactor the above to execute them --> hacky option to output JUnit here
• [x] Make all of the test/benchmark methods use callbacks instead of printing directly to stdout
• [ ] Create a curl handle mock for testing
• [ ] Pull ugly bits of the test/benchmark execute flow into common code for macro (split up execute steps). NEEDS SOME THOUGHT HERE.
  • Steps are radically different for test vs. benchmark.
  • Maybe need a skip callback for cases where nothing to test?
  • Setup/test/teardown? Context-before, template?
• [ ] Move run_testset pre/post macro logic into appropriate macro
• [ ] Somehow pull out the run_testset overall reporting... pass/fail/skip needs to be tracked in an object (this will map to a unittest TestSuite or something like that in JUnit)
• [ ] Move testset execution logic into testset object (macros)
• [ ] Optional: Class based registry for macros, where it does not just register parse functions (prototype for v2?) - this allows for API-level use (beta for use in the other extension points, where they look to see if it's a parse function or a class input to figure out how to use them)

Macro Execution Signature:

execute_macro(self, context=None, test_config=None, cmdline_args=None, callbacks=DefaultLogging, *args, *kwargs)

Lets you later first look for variables in self, then testConfig, then cmdlineArgs (which are a dictionary).

[svanoort]

@spradeepv - this is the precursor to #43 (xUnit output), which you were eagerly anticipating I believe. It's in scope for the next release assuming I can arrive at a reasonable implementation without completely hacking up the core code (and perhaps get some volunteers to play with it).

Once it's complete, generating the xUnit output should be fairly straightforward (fingers crossed). We just register a separate set of optional callbacks and use them instead (or in addition to) the normal logging. It also lays the groundwork for parallel test/testset execution, hopefully.

CC @jeanCarloMachado and @nirsegev and @parametrization and @nitrocode - I know you all are waiting for this too and might be interested in playing with alpha versions of JUnit output once available.

Worth mentioning that this represents a huge under-the-hood change to the core logic in PyRestTest (outwardly it will look similar, inwardly it will be much more straightforward and easy to add custom handling).