[WIP] subtle: breaking changes for a hypothetical v3.0

[tarcieri]

This commit contains a minimal set of proposed breaking changes, as an alternative to trying to make additive changes which may be "subtly" breaking:

• Add ConstantTimeClone trait and use it as ConditionallySelectable's supertrait bound (alternative to Add ConstantTimeSelect and ConstantTimeClone traits #118): this makes it possible to implement ConditionallySelectable on heap-allocated types (fixes Support ConditionallySelectable for types that are not Copy #94)
• Remove Default bound on CtOption::map and CtOption::and_then: allows using these methods with types that don't impl Default and avoids potential timing sidechannels if there might be timing variability in Default types (fixes Supporting CtOption::map for non-Default types? #63)

[tarcieri]

I think #118 might still be worth considering, in that since it relaxes bounds it isn't technically "breaking" (I believe), but would potentially result in code ceasing to compile if it was relying on the supertrait bound of ConditionallySelectable being Copy.

This PR is a "safer" option in terms of directly calling these changes out as breaking, but would split the subtle ecosystem between v2 and v3, which is rough given the trait-based API and how it's composed across crates.

One workaround, as I noted in #118, would be to use the "SemVer trick" and have subtle v2 optionally depend on subtle v3, which would make it possible for subtle v2 to add a blanket impl of its ConditionallySelectable for all types which impl subtle v3's ConditionallySelectable, as well as re-exporting the unchanged traits/types wholesale rather than defining them, which would allow a degree of interop.

[tarcieri]

If we do make breaking changes, we can completely remove this feature since it's now MSRV-compatible

[tarcieri]

Unfortunately we can't support anything other than Copy types here, since [T; N] receives a Copy impl for T: Copy, and that means it will receive ConstantTimeClone when T: Copy.

This means we can't add a blanket impl of ConstantTimeClone to [T; N] where T: Copy because it would overlap with the other blanket impls outlined above.

We could potentially add bounds like: Self: ConstantTimeClone, T: ConditionallySelectable + ConstantTimeClone, but that wouldn't actually be usable since [T; N] only receives a ConstantTimeClone impl for Copy types as described above.

What would be really nice here is some way of expressing disjoint bounds using hypothetical new type system features, e.g. being able to impl<T> ConstantTimeClone for [T; N] where T: ConstantTimeClone + !Copy

[tarcieri]

It might be nice not to explicitly use Copy here just to leave the door open for the blanket impl outlined above though

[tarcieri]

There's a similar problem where where we can't add a conditional ConstantTimeClone impl to CtOption<T> because it derives Copy and so already can receive the blanket impl.

[tarcieri]

Hmm, all of the complexity of these bounds has me wondering if we can just remove the Copy bound on ConditionallySelectable without any replacement, and eliminate any dependencies on Copy in the default methods.

[tarcieri]

Closing in #137 which avoids adding ConstantTimeClone by removing usages of Copy, and is significantly simpler