Various multibyte bugs

There are a number of multibyte bugs in this library.

1. [`str_replace()`](http://www.php.net/manual/en/function.str-replace.php) is not multi-byte safe, yet is used to escape any quote characters within SQL object identifiers.  For example:

    ```php
    // using GBK
    $db = new SafeMySQL(['charset' => 'gbk']);

    // malicious table name
    $table = "\x8c` WHERE user='admin' -- ";

    // other variables
    $mod = 'foo';
    $limit = 1;

    // example from documentation
    $data = $db->getAll('SELECT * FROM ?n WHERE mod=?s LIMIT ?i',$table,$mod,$limit);
    ```

    The query that is sent to the server:

    ```mysql
    SELECT * FROM `宍` WHERE user='admin' -- ` WHERE mod='foo' LIMIT 1
    ```

    Fortunately this vulnerability is somewhat mitigated by the fact that the statement will fail if the resulting identifier (the table name of `宍` in the above example) is not the name of a known object&mdash;and an attacker is limited in the identifiers that he can use, since the final byte must be `0x60` (an ASCII backtick); furthermore, since the query is dispatched with [`mysqli::query()`](http://www.php.net/manual/en/mysqli.query.php), [the server will ignore attempts to introduce a second statement](http://www.php.net/manual/en/mysqli.quickstart.multiple-statement.php).  So the exploit risk is low.

    The problem can however be fixed by using [`mb_ereg_replace()`](http://www.php.net/manual/en/function.mb-ereg-replace.php) instead of [`str_replace()`](http://www.php.net/manual/en/function.str-replace.php) and this is introduced by [my first commit](https://github.com/eggyal/safemysql/commit/a2d43a0c177400f4385effd7f692b3c4ac69c55d) (together with a few other OCD changes to string literals).

    [My second commit](https://github.com/eggyal/safemysql/commit/2a313198629afd35c0c14f62a7dbef9fa54cd7a1) then moves the [`mb_regex_encoding()`](http://www.php.net/manual/en/function.mb-regex-encoding.php) call (necessary to set the encoding for the above operation) into the `escapeIdent()` function in order to avoid problems if its setting is changed between object construction and statement preparation.

2. In searching for parameters using [`preg_split()`](http://www.php.net/manual/en/function.preg-split.php), `prepareQuery()` implicitly assumes that the raw statement is in ASCII&mdash;yet the user is allowed to choose alternative connection character sets.  This may not be an unrealistic assumption, since every connection character encoding that MySQL currently supports is a compatible superset of ASCII.  However, there's no sensible reason not to perform this operation in the connection character set, which is what my [third commit](https://github.com/eggyal/safemysql/commit/27352a73188c92905857df2765d6e0b668080653) achieves.

    As an aside, it may be worth noting that performing this split operation using regular expressions is somewhat naive.  For example, the raw query might contain a parameter code within a string literal:

    ```php
    $db->getAll("SELECT * FROM foo WHERE bar='hello?silly'");
    ```

    Here the library will attempt to replace the `?s` within the string literal.  Of course, in this example the query will fail due to a mismatch in the number of parameters and provided values&mdash;but it would be better to properly _parse_ the SQL to identify the context in which placeholder strings are encountered: [PHP SQL Parser](https://code.google.com/p/php-sql-parser/) might be useful to that end.  In the meantime, one might at least assert that the pattern should end on a word boundary.

3. On the same basis (i.e. that the SQL may be using an encoding other than ASCII), placeholder expansion must ensure that all values and inserted SQL code are encoded using that connection character set.  This is implemented in [my fourth commit](https://github.com/eggyal/safemysql/commit/2daff30e40a1c5e7d78aa4c9fcc37996e51440fa).