Seal traits that only intended to be implemented within the crate that defines them

[taiki-e]

Currently, crossbeam provides the following traits:
https://docs.rs/crossbeam/0.8.0/crossbeam/all.html

• atomic::AtomicConsume
• epoch::CompareAndSetOrdering
• epoch::Pointable
• epoch::Pointer

Some of these seem intended to be implemented for a particular type and not intended to be implemented by the user.
If I understand correctly, the traits below are not intended to be implemented by the user:

• epoch::CompareAndSetOrdering
  I don't think it makes sense to implement this other than Ordering and (Ordering, Ordering).
  EDIT: See Remove CompareAndSetOrdering trait and change compere_and_set to always use two orderings #621

• epoch::Pointer
  The document says it's a trait for Owned and Owned.

  A trait for either Owned or Owned pointers.

I would prefer to seal these traits using the sealed trait pattern described in API guidelines to prevent them from being accidentally implemented by the user. (Even if we never plan to make breaking changes to these APIs, I believe it's still worthwhile to prevent users from accidentally implementing these traits.)

[taiki-e]

If I understand correctly, the traits below are not intended to be implemented by the user:

For other traits:

• atomic::AtomicConsume
  As the document says, I think this is intended to be implemented for the atomic types of the standard library, but I don't think there is any problem if the user implements this.
  (That said, third-party crates can implement as an inherent method, so I don't think it's a problem to seal it.)

• epoch::Pointable
  cc @jeehoonkang: Is this trait intended to be implemented by the user? (I guess it's "true", but I'm not clear)

[jeehoonkang]

• For CompareAndSetOrdering: maybe we can completely switch to compare_exchange and always use two orderings for CAS?
  What do you think?

• Pointer: I agree that the sealed trait pattern would be nice for this trait.

• AtomicConsume: I agree that it's "open" to the library users.

• Pointable: it's intended to be implemented by the users who want to precisely control DST and memory layout stuffs.

[taiki-e]

• For CompareAndSetOrdering: maybe we can completely switch to compare_exchange and always use two orderings for CAS?
  What do you think?

Ah, given that the standard library deprecated the methods that use a single ordering for CAS operation, I think it makes sense to remove CompareAndSetOrdering trait and change compere_and_set to always use two orderings.

EDIT: opened #621 for this.