add the "safe" modifier to skip auto_escape

[lessmind]

{$var|safe}
{$var|safe|substr:5}
Above could skip the auto escape feature.

[xPaw]

I feel like these safety/autoescape features are silly inside the RainTPL, and should be left to users writing code/themes to filter stuff properly. This includes the sandbox mode, which basicly doesn't guarantee that there won't be an exploit that by-passes that. On top of that, it's just making RainTPL more bloated, and less speedy. I personally use this lib with sandbox and auto_escape disabled, and deal with that myself where I need to.

[lessmind]

Well, if it should be left to users writing code/themes to filter stuff properly, then apparently the auto escape feature is totally useless, since you can't turn it off in runtime, and turns out to be that you MUST turn it off and handle all by yourself.
Of course you can turn it off, but I think left the auto escape as true will be more security for my project.

[feulf]

This is an interesting pull request, I needed this functionality.

@xPaw sandbox and auto_escape have different responsibility, the first should make the code safe by PHP injection in those project where you load templates from untrusted sources, the second instead is to keep the page safe from javascript injection, read XSS, so for example blog, forums should have auto_escape always on. The sandbox it still need a great tune up.

I'll check your code and merge it to master.

[PMickael]

I think, It's better to do the opposite, with an |escape, we don't need this auto_escape by default, but maybe in some case you would like to, If you don't already have made this job done yourself like say @xPaw

[feulf]

so your suggestions are:
with auto_escape => true
use {$var|safe} to avoid the escape

with auto_escape => false
use {$variable|escape} to escape the variable

Yes, this is the best solution. All we need now is a modifier |escape.

We can add a new modifier autoload functionality, so any time a new modifier is called, if the function doesn't exists, RainTPL will load it from a modifier folder e.g. modifier/escape.php.

This should obviously be developed in another pull request, with priority on this, so when that is ready we merge in master and then merge this into master. Sounds like a good plan to me, do you agree?