convention for manually processed placeholders

(This issue is more like a start of a discussion than a problem)

I was building a task to prepare targets for grunt-contrib-concat. I'm concatenating locale files for [l20n](https://github.com/l20n/l20n.js)
Concat as we know grabs all the files matching certain pattern and concatenates them.
I needed the patterns to be grouped by the locale.

I tried to use default delimiters: `<%` and `%>` like this: `'app/modules/**/<%= locale %>.l20n'` but my task got those strings already preprocessed. Off course `locale` was not present in the grunt config so the whole placeholder was gone. And that wasn't what I've been looking for.

I found it useful to create my own set of delimiters:
`grunt.template.addDelimiters('mustache', '{{', '}}');`
so my patterns now look like: `'app/modules/**/{{= locale }}.l20n'` and my task is supposed to do the processing for those delimiters.

That solved the case but other team members got confused seeing something like `'app/modules/**/{{= locale }}.l20n'` in the review.

Grunt-contrib-concat suggests [how to achieve "dynamic filenames"](https://github.com/gruntjs/grunt-contrib-concat#advanced-dynamic-filenames). My case is a bit more complicated because I'm creating whole groups based on a collection of strings. In this case they're names of the locales.

I'm quite convinced concatenating locale files it not the only case where grouping (or any other job incorporating in-task source pattern preprocessing) will be useful. What I'm suggesting is to elaborate the convention of placeholders that won't be automatically processed but should be processed by the task. I used `{{` `}}` but there may be other delimiters off course.

Start with grunt.template.addDelimiters and the grunt-contrib-concat guidance on dynamic filenames, then review how task patterns are preprocessed. Done means the project has an agreed convention for placeholders intended for manual task processing, with the behavior and delimiter choice documented; no source file or test is named.

Written by the indexing model from the issue text.