Refactor internals so statics work with internal objects

Right now it would be difficult -- if not impossible -- for FUnit to test itself. This is generally a Bad Thing, I think. These are some notes on a potential solution.

One reason it's so challenging is that using statics for _everything_, including internal tracking of tests and results, means there can only be one of everything, including the array of run tests, assertion tracking, etc.

_Note that a lot of the ideas here would be similar to how Slim's $app objects are created and tracked_

I suspect that a good approach would be to have a TestSuite object internally. When we call FUnit::test(), tests would be attached to that object.

`class TestSuite`
- `tests` (attached with `FUnit::test()`)
- `setup_func` (attached with `FUnit::setup()`)
- `teardown_func` (attached with `FUnit::teardown()`)
- (new) `before` - runs before the suite starts (attached with `FUnit::before()` (new))
- (new) `after` - runs after the suite finished (attached with `FUnit::after()` (new))

By default, everything is attached to a 'default' `TestSuite`. You can start separate suite, though, by calling `FUnit::test_suite($name)` (new). All subsequent calls to methods like `FUnit::test()`, `FUnit::setup()`, and ``FUnit::teardown()` would apply to that new `TestSuite` object.

Calling FUnit::run() would "close" the current suite. If FUnit::test() is called after a run, a new `TestSuite` would automatically be created.

In addition, there should be a way to retrieve a `TestSuite` by the name (`FUnit::getSuite($name)`), and then directly attach tests and run the suite (probably via standard OOP method calls). That way we could create one test suite that makes FUnit static calls, and make assertions against a second test suite created by those calls.