initial codeception test suite

Here are tests run with Codeception engine. Basically, in those tests Codeception does nothing special that PHPUnit can't, yet it looks like the tests lacked a proper structure. So moving tests into Codeception should be not just changing the file location, but also some refactoring in order to gain more readability and maintainability of tests. The ideal test is that can be taken into documentation. 

``` php
<?php
    public function testTagSelect()
    {
        expect(
            Tag::select(array(
                'some_name',
                \Robots::find(),
                'using' => array('id', 'name')
            ))
        )->equals(
            '<select name="some_name" id="some_name">' . PHP_EOL
            . chr(9) . '<option value="1">Robotina</option>' . PHP_EOL
            . chr(9) . '<option value="2">Astro Boy</option>' . PHP_EOL
            . chr(9) . '<option value="3">Terminator</option>' . PHP_EOL
            . '</select>'
        );
    }

```

Looks a way like a documentation. Or:

``` php
<?php
    public function testUrlForControllerAction()
    {
        $this->router()
            ->add('/admin/:controller/p/:action', array('controller' => 1, 'action'=> 2))
            ->setName('adminProducts');

        expect(
            $this->url()->get(array(
                'for'        => 'adminProducts',
                'controller' => 'products',
                'action'     => 'index',
            ))
        )->equals('/admin/products/p/index');
    }

```

So I'd like to propose some simple rules for writing tests:

* separation helpers from tests. All preparation methods should be moved into helpers. Thus, no Model/TestCase ierarchy needed. 
* usage of `expect()` instead of assertion. This is taken from Codeception/Verify project. A bit more readable then `assert`. Much easier to get what is actual, and what is expected.
* docblocks should not be used for comments. Currently they are just the source of confusion: Because of this :( 
https://github.com/DavertMik/cphalcon/blob/Codeception/php-tests/tests/Phalcon/Url/UnitTest.php#L190
* and yes, the shorter tests are, the more are they easy to maintain. 
* test name is exact the same name of tested class + "Test" suffix.

-----

File Structure:

tests are in `tests` dir. There are 3 suites: 

* functional - TestGuy (not used)
* integration - DbGuy - with database - PhalconDbHelper  + PhalconApiHelper
* unit - CodeGuy - without database - PhalconApiHelper

*Guy classes contain all passed methods from Helper classes. They are generated with `built` command in order to provide multiple inheritance from helpers/modules. Take a look into `tests/_helper` files, and especially PhalconDbHelper and PhalconApiHelper.

All data (fixtures, etc) should be put into `tests/_data` dir.


---

Run Tests:

```
php codecept.phar run 

```

Run Unit Tests:

```
php codecept.phar run unit

```

Run Integration Tests:

```
php codecept.phar run integration

```

Run only Tag test

```
php codecept.phar run tests/unit/Phalcon/TagTest.php 

```

----

Generate new unit test for Phalcon\Mvc\Router class

```
php codecept.phar generate:test unit "Phalcon\Mvc\Router"

```



P.S. Currently integration tests run for MySQL only. That's limitation of Codeception which I'm going to fix in next version.
P.S.S. RIght now some Tag tests are failing. Not sure why :(