Encoding Support

Taking a crack at the encoding problem (#75). The code I have written so far is pretty close to @judofyr's original write up on that issue. The `Template` class has been modified somewhat and I'm using the `ERBTemplate`, `BuilderTemplate`, and `CoffeeScriptTemplate` implementations to exercise the requirements.

I have a section in the README on encodings to spec out the expected behavior and general strategy. There's an overviewy part and then it describes how templates should think about template source data:

> ### Template Source Encoding
> 
> The template source data may come from a file or from a string. In either case, the real template source encoding should be determined as follows in order of preference:
> 
>  - Template specific encoding rules (e.g., utf-8 only formats).
>  - A (template specific) magic encoding comment embedded in the source string.
>  - The source string's existing encoding (string only).
>  - The `:default_encoding` option to `Template.new` (file only).
>  - `Encoding.default_external` - the default system encoding (file only)
> 
> Some template file formats have strict encoding requirements. CoffeeScript is a utf-8 only format for instance. Template implementations are encouraged to use this type of information to constrain the detection logic defined above.

This part feels pretty solid to me. The ERB/Erubis, Builder, and CS templates all adhere to these rules and document their behavior when the source encoding detection process is somehow constrained.

This next part I've only prose and no code. It's a lot more shaky:

> ### Render Context Encoding
> 
> When the system internal encoding (`Encoding.default_internal`) *is not* set (MRI default), templates should be evaluated and produce a result string encoded the same as the template source data. e.g., A Big5 encoded template on disk will generate a Big5 result string and expect interpolated values to be Big5 compatible.
> 
> When `Encoding.default_internal` *is* set, templates should be converted from the template source encoding to the internal encoding *before* being compiled / evaluated and the result string should be encoded in the default internal encoding. For instance, when `default_internal` is set to UTF-8, a Big5 encoded template on disk will be converted to and generate a UTF-8 result string and interpolated values must be utf-8 compatible.

I do like this behavior in theory. It's compatible with ActionView and seems consistent with the spirit of `Encoding.default_internal`. However, the caller needs the ability to override these behaviors for cases where `default_internal` cannot be changed but the caller knows render context transcoding is needed or not needed. For that I think we should add another option:

> Templates that perform render context transcoding must allow these default behaviors to be controlled via the `:transcode` option:
>
>   - `:transcode => true` - Convert from template source encoding to the system default internal encoding before evaluating the template. The result string is guaranteed to be in the default internal encoding. Do nothing when `Encoding.default_internal` is nil.
>
>     This is the default behavior when no `:transcode` option is given.
>
>   - `:transcode => false` - Perform no encoding conversion. The result string will have the same encoding as the detected template source string.
>
>     This is the default behavior when `default_internal` is nil.
>
>   - `:transcode => 'utf-8'` - Ignore `default_internal`. Instead, convert from template source encoding to utf-8 before evaluating the template. The result string is guaranteed to be utf-8 encoded. The encoding value (`'utf-8'`) may be any valid encoding name or Encoding constant.

My plan is to start working on the default transcoding behavior + `:transcode` option for all of the templates I've touched so far. What do you guys think?

/cc @judofyr, @josh, @rkh, @josevalim, @apotonick, @nesquena, @brianmario, @DAddYE, everyone ...