Document policy on backporting features to older C++ dialects

[jrhemstad]

libcu++ makes some library features of the STL available in older C++ dialects, e.g., type_traits and chrono.

We should document our policy for what features libcu++ will backport.

From @brycelelbach:

I think that policy should be whenever it is possible to implement a
library feature from a newer dialect in an older dialect, we will do so. If
the library feature depends on newer language features, then we shouldn't
backport it. If it uses newer language features, but they aren't core to the
facility or change, then we should make a best effort. For example, C++17
string_view has deduction guides, which are a C++17 language feature, but they
are not central to the design of string_view.

There is some concern that this could decrease portability where a user of libcu++ uses backported feature X and then switches to another standard library where feature X is not available in the same C++ dialect.

We could:

• Do nothing and just backport features.
• Make it opt-in.
• Make it opt-out.
• Provide an opt-in warning mode.
• Provide an opt-out warning mode.
• Only do it in cuda::std but not in std.