WIP: Fuel-Tables 1.0

A Bootstrap 3.0.0-wip style pull-request to switch from the current version 0.1-dev to 1.0. This is an ongoing document to identify the changes to make and made along the way.

## Countable:
- [x] ```count($table) = $num_of_rows``` Count a table => Result is number of rows (i.e., without header and footer)
- [x] ```count($row) = $num_of_cells``` Count a row => Result is number of cells
- [x] ```count($group) = $num_of_rows``` Count a group => Result is number of rows (only works for body as header and footer have to have just one row)

## Magic Methods:
- [x] Allow setting header, footer, rows magically by doing $table->header = array(); OR $table->header = \Table\Header::forge(); Same applies for footer and rows
- [x] All other setting data goes to attributes of the wrapping table

## Objectized:
- [x] Every row is an object having its own $_attributes
- [x] There are three groups to wrap row(s) into
    * Header
    * Footer
    * Body
- [x] There is one type of row for each group
- [x] Every group can have attributes as well e.g., ```<thead class="table table-head">```

## Data Import:
- [x] Data can be imported manually (by calling $table->add_row() or $table->add_rows())
- [ ] Data can also be imported by assigning a (namespace) model

## Data Display:
- [ ] Data can be filtered
    * Manually by calling filter($column, $value) (allow regex-syntax for $value)
    * Automatically by calling filter(true) or filter($config) with $config being an array of important info where to find stuff inside the URI (e.g., which $_GET-key is used for the filter-column, which for the value, if it's GET or POST)
- [ ] Data can be paginated
    * Manually by calling limit($limit) and offset($offset)
    * Automatically by calling paginate(true) or filter($config) with $config being an array of important info where to find stuff inside the URI (e.g., which $_GET-key is used for limit, which for offset, if it's GET or POST, whether it's a page or limit/offset styled-display, default 'per-page')
- [ ] Data can be sorted
    * Manually by calling sort($column, $dirn)
    * Automatically by calling sort(true) or sort($config) with $config being an array of important info where to find stuff inside the URI (e.g., which $_GET-key is used for column, which for dirn, if it's GET or POST)
- [ ] Allow appending/prepending content to a td's content
    * $table->body->append('username', 'icon'); // Appends a static content
    * $table->body->append('username', function($username, $user) { return 'icon-' . $username; }); // Appends using a closure

## Sanitation:
- [x] Data can be sanitized with sanitizers. Thus, each td's content will be run through a sanitizer if necessary (depends on value set for column-header/name)
- [ ] Allow overriding and appending of sanitizers for each column
    * $table->sanitize('username', 'strip_tags', true); // Overrides
    * $table->sanitize('username', 'strip_tags'); // Appends

## Configuration:
- [ ] General configuration done in app/config/table.php
- [ ] Per-table instance configuration
    * Either passed along to new/forge()
    * Configured via $table->init()
- [ ] Configuration takes care of
    * Pagination options
        * Per page
        * Via GET/POST
            * which key is page OR
            * which key is limit/offset
    * Filtering options
        * Default filtering to apply (e.g., array('status', '!=', '0')) (just makes sense for per-instance config not as a global)
    * Sorting options
    * Styling
        * Can be done by using wrappers from app/config/table.php
        * Default attributes can be set here e.g., default class for table, thead, tbody, tfoot, tr, td, ...