ck_hs: Migrate to ck_pr_fence_X_Y.
ck_epoch: Elaborate on ck_epoch_register load fence.
ck_hp_fifo: Finer-grained mapping to ck_pr_fence_X_Y.

Specifically, atomic-RMW fences were previously generalized
as store operations.
ck_fifo: Migrate MPMC FIFO to ck_pr_fence_X_Y.
doc: Add ck_pr_fence_atomic manual page.
doc: Add ck_pr_fence_atomic_X manual pages.
doc: Add references to ck_pr_fence_atomic_X.
ck_pr: Get rid of ck_pr_fence_X_X functions.

These add unnecessary complexity to the ck_pr_fence interface.
Instead, it can be safely assumed that developers will use
ck_pr_fence_X to enforce X -> X ordering.
doc: Add ck_pr_fence_load_X manual pages.
doc: Add ck_pr_fence_store_X manual pages.
build: Only copy generated files if out-of-source.
ck_spinlock: Only enable trylock for ck_spinlock_ticket on x86*.

trylock algorithm semantics are not cleanly defined outside of x86.
ck_pr: Implicit compiler barrier ck_pr_fence.

I accidentally removed ck_pr_fence implicit compiler
barrier semantics in re-structure of ck_pr_fence.
This does affect the correctness of any data structures
in ck_pr_fence or the correctness of consumers of ck_pr
operations where ck_pr serves as linearization points.
The reason it does not affect any CK data structures is
that explicit compiler barriers (whether they are store/load
operations or atomic ready-modify-write operations) always
serve as linearization points.

However, if consumers are doing tricky things like using
these barriers to serialize aliased locations for correctness,
then it is possible for compiler re-ordering to bite them in
the ass.
Merge branch 'master' of https://github.com/sbahra/ck
Merge branch 'master' of https://github.com/bscheinman/ck