feat(whiskers): support alternative template file encodings

[backwardspy]

currently supports whatever encodings the encoding_rs_io crate supports

there are test cases for UTF-8, UTF-8 with BOM, UTF-16 LE, and UTF-16 BE.

resolves #178

BEGIN_COMMIT_OVERRIDE
feat(whiskers): support alternative template file encodings
END_COMMIT_OVERRIDE

[nekowinston]

Did you consider an alternative of keeping the target file encoding in the whiskers metadata?
From my own experience where encoding mattered (Hearts of Iron IV modding, lol), keeping track of the correct encoding can be a tad annoying.
e.g.

whiskers:
  encoding: utf8-bom
  version: "2.1.0"

instead of requiring the input to have the same encoding as the output.
Edit: and as this PR diff shows, it would help with git diffs in the be edge cases.

[backwardspy]

whiskers:
  encoding: utf8-bom
  version: "2.1.0"

i hadn't considered that, but i like the idea! i think i'll tackle encoding in another PR as the choice of crates for this stuff seems to be split around decoding & encoding. i imagine i'll need to bring in another dependency for it.

instead of requiring the input to have the same encoding as the output.

right now we only care about the file encoding on input, all outputs are utf-8 per rust's defaults. those utf-16 files in the diff are fixtures for tests that ensure we can read & render those files correctly.

[nekowinston]

right now we only care about encoding on input, all outputs are utf-8 per rust's defaults. those utf-16 files in the diff are fixtures for tests that ensure we can read & render those files correctly.

oh I misunderstood this PR, I guess this would've been a better comment to make in #178 🙃
seems fair to split it in two PRs then 👍

[backwardspy]

to be fair, i did imply on that issue that i could carry the encoding through to writing the file too. i much prefer your solution.