std::filesystem support with polyfill

[jwnimmer-tri]

We'd like to use std::filesystem in lieu of spruce.

It looks like std::filesystem is still only std::experimental::filesystem in Ubuntu 18.04 (Bionic) and macOS Mojave (10.14), but will be non-experimental as of Ubuntu 20.04 and macOS Catalina (10.15).

Therefore, my plan would be to use https://github.com/gulrak/filesystem (aka ghc::filesystem) as polyfill for OS versions without standard library support, but to use the standard library when available (as we do with, e.g. std::optional).

Once we drop support for Mojave 10.14 (i.e., when 10.16 comes out) such that Bionic is the only straggler, we could image dropping ghc::filesystem and using std::experimental::filesystem with -lstdc++fs if we'd like to lose the extra dependency.

The questions for ghc::filesystem is whether we compile it as single-header vs separate, and whether we allow it as a public dependency (from h files) or only private like with spruce currently (only from cc files). My current thought is to start with private.

WIP at https://github.com/jwnimmer-tri/drake/commits/filesystem

\CC @jamiesnape @EricCousineau-TRI

• Add new ghc::filesystem dependency (Add drake::filesystem via new ghc::filesystem dependency #12106).
• Remove all uses of spruce.
• Upstream ghc::filesystem patch for deprecated constexpr warnings (Fix storage deprecation warning when in C++17 mode gulrak/filesystem#31).
• Upstream ghc::filesystem patch for old style cast (Fix old-style-cast warnings gulrak/filesystem#32).
• Deprecate downstream use of spruce (workspace: Deprecate @spruce #12182).

[jamiesnape]

single-header vs separate,

Separate, using the wrapper headers? I think I have a mild preference for separate, depending in part on whether the dependency is private (my preference is stronger if it is public).

My current thought is to start with private.

Agree.

[jwnimmer-tri]

My WIP uses separate compilation, but without the wrapper headers. By rolling our own presence check, we can avoid all dependency on ghc for users who have a sufficiently new toolchain, which is nice for commercial users who have to separately vendor every source dependency of Drake (which includes both TRI and other companies).

[jamiesnape]

That sounds good to me.

[jwnimmer-tri]

In #12106 we'll add ghc::filesystem. Future PRs will work to remove @spruce. We should also upstream some old-style-cast warning fixups.

[jwnimmer-tri]

As of #12182, @spruce is never used internally in Drake, and is deprecated for use by downstream bazel projects. (It was never available downstream to CMake projects.) After the 3-month window, it will be removed from the source tree.