SQL_NO_CACHE / SQL_CACHE only handled/optimized by qc, if used in the right order

when using

SELECT sql_some_hint SQL_NO_CACHE ...

or

SELECT sql_some_hint SQL_CACHE ...

the query cache 'parser' don't check for SQL_CACHE/SQL_NO_CACHE if it's not after "SELECT", we should check more bytes after "SELECT" to make sure we don't have "SQL_NO_CACHE"/"SQL_CACHE" hint, i think 50~100 bytes of search is ok, but we can have some situations like

SELECT /* comments more than 100 byts */ SQL_CACHE/SQL_NO_CACHE   -- must read only hints, not comments

or

SELECT /* comment SQL_CACHE */ SQL_NO_CACHE ...  -- should not cache

or

SELECT /* comment SQL_NO_CACHE */ SQL_CACHE ...  -- should cache

must check what's a nice number to have as 'buffer size' to execute this "HINT" search

1. a idea is search one space after each hint, we could check 10 spaces, if SQL_NO_CACHE / SQL_CACHE isn't found, continue checking qc normally as we don't know if hints are present or not without executing the "real" parser
2. another idea is search for 50~100 bytes after "SELECT"
3. run query cache before and after parser (to execute a 100% SQL_NO_CACHE / SQL_CACHE search)