Describe the bug
zend_inline_hash_func creates collisions http://www.phpinternalsbook.com/php5/hashtables/hash_algorithm.html#hash-collisions

In our specific case Phalcon\Mvc\Model\Query::parse() creates exactly same ast for different phql causing us to return same values for different queries because we store ast representation in cache, which hash we build using zend_inline_hash_func.

We have pretty long ids(for elasticsearch, custom implementation) but we use parse method of phalcon query anyway. I guess this is possible to reproduce as well to use use same namespaces etc.

I know that partially the issue here is that we put id value in query - but still we should maybe use better algortihm for this hashing.

Also the issue here is that we tried to set phalcon.orm.parser_cache in php.ini to disable this functionality but none of values worked, like -1, php ini_get always returns false

I'am going also to provide PR with simple test, hopefully it will fail too.

To Reproduce

Steps to reproduce the behavior:

Run code below

Provide minimal script to reproduce the issue

        $ast1 = \Phalcon\Mvc\Model\Query\Lang::parsePHQL("SELECT [TagMe\Modules\Identity\Infrastructure\User\Model\Elasticsearch\Users].* FROM [TagMe\Modules\Identity\Infrastructure\User\Model\Elasticsearch\Users] WHERE _id = 'GcbN9FIoI8IC3LqBIuCu50AC02TpI8ruKOjyzd1fqOCuna' LIMIT :APL0:");
        $ast2 = \Phalcon\Mvc\Model\Query\Lang::parsePHQL("SELECT [TagMe\Modules\Identity\Infrastructure\User\Model\Elasticsearch\Users].* FROM [TagMe\Modules\Identity\Infrastructure\User\Model\Elasticsearch\Users] WHERE _id = 'GcbN9FIoI8IC3LpcIuCu50AC02TpI8ruKOjyzd1fqOCuna' LIMIT :APL0:");
// it should be the same ast representations

Expected behavior
Return different ast representation so query will work.

Details

• Phalcon version: 3.4, but should happen on 4.0 as well (php --ri phalcon)
• PHP Version: 7.2.26
• Operating System: Ubuntu 16.04
• Installation type: Compiling from source
• Zephir version (if any): not related, we use zend function internally
• Server: Nginx
• Other related info (Database, table schema): elasticsearch, but not related in that case