Account for callr:r()'s handling of .Rprofile

[jennybc]

Closes #340
Closes #284

This ended up playing out in 3 specific ways:

• Make sure that callr:r() sees the reprex working directory as working directory, so that a project-specific .Rprofile callr loads is guaranteed to be same as the .Rprofile in working directory during reprex execution. I would regard reprex()'s behaviour w.r.t. this ever since callr's default changed to be ... undefined and/or wrong and/or surprising. With this behaviour, reprex()'s behaviour makes sense, by design.
• The usage of a local .Rprofile will now be indicated in the rendered reprex. I'm not 100% certain we should do this. In principle, it feels right, but there will be contexts where this may be annoying (e.g. reprex_rtf() for slides). Then people will want to be able to turn it on/off. Is the hassle worth it?
• The usage of a local .Rprofile now generates a user-facing alert. I'm almost 100% certain this is a good idea and won't face much resistance. Here's what that message looks like:

> reprex(x, outfile = NA, advertise = FALSE)
✓ Preparing reprex as `.R` file:
  reprex1214e62c2bd6c_reprex.R
! Local `.Rprofile` detected in reprex directory:
  /private/var/folders/.../reprextests-bbb-1214e74d0bd1d/.Rprofile
ℹ Rendering reprex...
✓ Writing reprex file:
  /private/var/folders/.../reprextests-bbb-1214e74d0bd1d/reprex1214e62c2bd6c_reprex.md
✓ Rendered reprex is on the clipboard.