Nvm this doesn't work.

@asraa @htuch more context of this PR:

• Before fuzz: fix filesystem bug, use std::__fs::filesystem #7507, in the libc++ build path we didn't have real dependency to libc++fs.a, which only exists in libc++ < 9.0, so deleting -lc++fs was fine.
• Before [envoy] define force_libcpp=enabled google/oss-fuzz#2586, -lc++fs isn't passed in fuzz build but -lstdc++fs was, this was fine because libstd++fs.a exists in fuzz image and envoy wasn't rely on any symbols from it.
• After [envoy] define force_libcpp=enabled google/oss-fuzz#2586, -lc++fs is passed in fuzz build but fuzz is running with clang 9, -lc++fs will result error as it doesn't exist.

This PR changes #7507 a bit to only use std::__fs when libc++ >= 9.0, so -lc++fs isn't needed in any case. This will unblock #7329 and fuzz build together.

This is fine to unblock oss-fuzz. It's a bit mind boggling how complicated getting a few filesystem libraries is in the C++ ecosystem. To me, this seems a failure in how Clang is handling the rollout of these new libraries, it should be much simpler to just condition on version without also needing to juggle the link complexity.

Agreed, actually #7507 is needlessly complicated and I can clean it up more.

Thank you so much for the context as well, @lizan