Contemplate callr:r()'s user_profile argument

[jennybc]

The default behaviour for the user_profile argument has changed since reprex last got serious attention:

3.4.0 (2019-12-09) system_profile = FALSE, user_profile = "project",
2.0.0 (2018-01-28) system_profile = FALSE, user_profile = FALSE,      <-- I think my use of callr is designed for this
1.0.0 (2016-06-18) system_profile = TRUE, user_profile = TRUE,

Documentation for the argument:

Whether to use the user's profile file. If this is "project", then only the profile from the working directory is used, but the R_PROFILE_USER environment variable and the user level profile are not.

In normal usage, I think it's OK that reprex is ignorant of user_profile because by default we reprex in the temp dir and, therefore, no .Rprofile is used by callr::r().

But if outfile is used, a project-level .Rprofile is potentially used. At the very least, this feels like something to be analyzed and documented. It's conceivable I should set user_profile = FALSE in reprex (that would be the most conservative approach in terms of not allowing changes in callr to change behaviour of reprex r-lib/callr#135 (comment)).

[jennybc]

This is also connected to #284, which is whether / how to acknowledge projects that use renv, which relies heavily on .Rprofile.

[jennybc]

Discussed with @hadley. We're going to try letting this happen, but we should make it such that the final reprex output contains evidence that a local .Rprofile was used (and message about this).