Extra context: API + CLI

Fixes #12
Synthesizes parts of: #75, #100, #116, #161 and #199.
Thanks @fcurella, @aventurella, @emonty, @schacki, @ryanolson!
(Not quite sure what you mean by "...to reverting")

To explain a bit my philosophy on encoding arguments, if you just have a text file's name, you don't have enough information to read the content, because you have no way to know the encoding. So you should never pass a filename alone to a function that reads a file. At least, not without understanding what you're doing ;-) In particular, I dislike wrappers round stdlib functions that simply allow you to omit the encoding - they can't decide for you, so they usually end up guessing wrong at times.

Your functions are essentially a re-implementation of the old ```unicode_open``` function that I replaced with ```io.open```. Looks like this one never used ```unicode_open```.

The current situation with Cookiecutter is that the utf8 encoding is assumed everywhere, and I want to try to make that assumption explicit - hence my switch to ```io.open``` with an explicit encoding. The next step will then be to check each of those places to determine (a) if the UTF8 assumption is justified, (b) whether the user might benefit from a choice, and (c) what standards (YAML, JSON, ...) need to be taken into account.

Having said that, grepping for your utility function is no harder than grepping for ```utf-8```, so it's a minor point. The problems with ```unicode_open``` have been fixed, and refactoring out the function doesn't reintroduce them in any way, so no problem there.