Feature request: Change default library path on Windows

Hello,

I'd like to propose moving the default library install location on Windows from:
%USERPROFILE%/Documents/R
to some other location such as:
%USERPROFILE%/R

For many users the Documents folder is backed up or synchronized.
Installing libraries thrashes Documents, and it causes synchronization
issues with Dropbox (I confirm this one), OneDrive, and users with
Network IT policies.

The vast majority of R users won't touch that folder and don't need it
backed up. And, its contents are not really "documents".

I very much support this request. R's behavior of defaulting HOME to
an unusual (legacy) directory is also a source of bugs and
interoperability problems:

R packages that interface c/c++ libraries that require a user config
file (libssh, libgit2, etc) sometimes cannot find the user config
because it gets stored on a different location than expected. A good
example is 'git'. The 'git for windows' command line utility stores my
user config in C:\users\Jeroen\.gitconfig. However, for R packages
that link to libgit2 (e.g. git2r, gert) the user config gets
loaded/stored from C:\users\Jeroen\Documents\.gitconfig because
libgit2 inherits the R home directory. Having 2 different git
configurations is obviously confusing for users.

Another problem is that when you start R from "windows bash" or the
msys2 shell (including "git for windows" or rtools40), the "~"
directory is different than in RGui. This is because these shells do set
the HOME variable (to the usual value), and R inherits that.

For example: when I start R in RGui for Windows I see:

  > normalizePath("~")
  [1] "C:\\Users\\jeroen\\Documents"

But when I start R or Rterm from the "git for windows" shell we get:

  > normalizePath("~")
  [1] "C:\\Users\\jeroen"

An ambiguous home directory is obviously going to break R code that
refers to paths in your home.

Because these problems affect all Windows users, I think the benefits
of fixing the default behavior easily outweigh the
backward-compatibility and "there is a documented workaround"
arguments.