ClassFormerlyKnownAsTemplateParser

@ivantcholakov
This discussion is primarly about the funcionality. Parser vs template engine. And it will be a completly new thing not a fork of Lex or clone. I think we only need the same or a litte better functionalty then what provided by Lex at least that stands for my needs...

1. 3. 4. About the regular expressions you're right, it's a very ugly way... I think they chose it because it's the simliest way to implement the parsing. But for a simple parser we really need something more?
2. I confirm this too, it can be a pain in... But in case of CI's parser I think this can be solved.
5. I can't remember a problem with this.
6. Yes you're right, but Lex not will be used!
7. My first job would be to turn it off... HTML escaping should be incorporated but the developer should choose when he wants to use it. There should be a specific syntax for it just like in Laravel's Blade { var } vs {{ var }}
8. It's only a parser not a template engine. If we will get an output cache, then the caching should be independent because any output should be cacheable and that output can be produced by a simple view call, by the parser, return html, json etc...