[rush] Add support for specifying a system-wide build cache location.

[iclanton]

This is one of the TODO items listed in #2393 (comment)

This change introduces an ~/.rushrc.json file that allows a "buildCacheFolder" to be specified. If this is provided, the cache is stored in this location instead of in each repo's /common/temp/build-cache folder.

[octogonz]

This change introduces an ~/.rushrc.json file that allows

Ideally this file should be called ~/.rush/rush-user.json so that we have a nice folder where we can later add other files as needed. Similar to how ~/.vscode has multiple files for VS Code.

However I think we made a mistake by designing ~/.rush to be a temporary folder that gets deleted by rush purge --unsafe. We could rename it to ~/.rush-temp (or ideally ~/.rush/temp) that would carry a small risk that an old release of Rush might delete the ~/.rush folder.

🤔 @iclanton What if we call the file ~/.rush-user/settings.json? (Maybe we should also deprecate ~/.rush and rename it to ~/.rush-temp?)

[D4N14L]

I'm wondering, could this new user config file/location also be used for package manager specific args? I had mused on this over in issue #1994 @iclanton ?

[iclanton]

It seems like a logical place. Would you imagine a structured config file for specifying options that are normally in a .npmrc file?

[D4N14L]

@iclanton similar? PNPM uses .npmrc but Yarn does not. Also, I believe PNPM should respect user-specific .npmrc files (https://pnpm.js.org/en/npmrc). It would be more of a place to provide a common interface with the options to pass into the package manager the Rush project is using.

Though, that would likely fragment over time with the different capabilities of different package managers. So maybe a structured config file where you can provide a list of arbitrary CLI args to append to the package manager call? Then we're getting into territory where the user could easily mess up their installs. I believe this is how we came to the idea of an "allow list" in the original issue, to avoid broken installs. However, the list would need to be kept up to date with package manager tweaks to newer versions over time, which isn't great. Maybe we do the allow list and allow arbitrary args if the user sets some allowArbitraryArguments value to true. Hmm...