convert path to the native locale before passing to boost::interprocess::file_mapping()

[yutannihilation]

fixes #834, fixes #837

As described on #834, the behavior of normalizePath() (more precisely, path.expand(), which is used inside normalizePath()) has been changed to return the character encoded in UTF-8. I guess this happens only with Windows on non-UTF-8 locales.

R 3.4.4 on Windows 10:

Encoding(normalizePath("~/鬼"))
#> [1] "unknown"

R 3.5.0 on Windows 10:

Encoding(normalizePath("~/鬼"))
#> [1] "UTF-8"

This usually doesn't become a problem; on R codes, most R functions take care of the encoding automatically. But, on C++ codes, the encoding attribute is lost when the String is converted to std::string. So, we need to convert it to the proper encoding before passing it to the functions that take std::string, in this case, boost::interprocess::file_mapping() here:

readr/src/SourceFile.h

Lines 19 to 20 in 6f0bb65

	fm_ = boost::interprocess::file_mapping(
	path.c_str(), boost::interprocess::read_only);

It seems boost::interprocess::file_mapping() takes the path string encoded in the native locale (CE_NATIVE). So, we need to ensure the string is encoded properly, instead of blindly pass the one passed from R session.

IIUC, Rcpp doesn't have a function to do this, so Rf_translateChar() is the choice in this case. (I'm not an Rcpp expert, so please point out if I'm wrong at this point....)

[yutannihilation]

@jimhester Do you also prefer enc2native(normalizePath()) solution here as with the case of readxl?

[jimhester]

Could you add a note mentioning this change and the PR number and we can merge this

[jimhester]

I think it is more clear if this is a CharacterVector rather than a SEXP.

[yutannihilation]

Thanks for the comment about avoiding vague SEXP. I've made a change. Is this what you mean?

[yutannihilation]

@jimhester Do I need to make more changes? If no, I think this is ready to merge now :)

[jimhester]

Thanks!

[yutannihilation]

Thanks for merging!