Push re-encoding of xls path into XlsWorkBook constructor

[jennybc]

I'm making this PR to restore symmetry of read_xls_() and read_xlsx_(). I want their signature and body to be the same (for eventual de-deduplication). The symmetry was lost at the time of the Rcpp --> cpp11 conversion (33c79a5).

General recap of this path handling:

• User's path needs to be normalized to expand, e.g., a leading ~/. At least for xls, we need to do this (see xls path containing the "~" shortcut can't be read #498).
• As of R 3.5, normalizePath() (path.expand(), really) returns UTF-8 encoded output, even if the input was not UTF-8.
• Once we adopted cpp11, it also does automatic conversion to UTF-8 for strings.
• This is fine for xlsx because we ultimately open the file with R (see zip_buffer() in R/xlsx-zip.R).
• For xls, we need to re-encode to the native encoding before we pass the path to libxls, which uses fopen().

Relevant previous history:

• Make sure path is in native encoding #477
• Normalize all paths, prior conversion to native encoding #499

[jennybc]

@gaborcsardi Will you just provide a quick look? I've tried to summarize how we got here and I'm quite confident this is reasonable.

[gaborcsardi]

For xls, we need to re-encode to the native encoding before we pass the path to libxls, which uses fopen().

FWIW this will not work on Unicode paths if they cannot be represented in the single-byte native encoding, and _wfopen() should be used instead on Windows. But you probably already know this, and I understand that you might not want to fix this in this PR.

Looks good otherwise.

[jennybc]

But you probably already know this, and I understand that you might not want to fix this in this PR.

I consider this a libxls problem. I guess I could open an issue or even a PR there, but I think I've got higher priority stuff to work on in readxl.