Expose `asymmetric_light_barrier` and explain its usage

We sometimes need to directly use the `protect_raw` function in `HazardPointer`, especially to implement some data structures where protection is validated in a different way. [Michael-Scott queue](https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf) or [DoubleLink Queue](https://concurrencyfreaks.blogspot.com/2017/01/doublelink-low-overhead-lock-free-queue.html) are good examples. To implement those with plain hazard pointers, after protecting the next node of the head node, its validation must be done by checking the entry pointer to the head node again. This is because the next pointer on the head node won't be changed even after the nodes are dequeued and retired.

**However, as the internal light barrier implementation is not public, we cannot synchronize the reading thread with the reclaiming thread.** Of course, using `fence(Ordering::SeqCst)` might be enough, because the current implementation of the light barrier is just a sequential normal barrier. Nonetheless, It would be good to allow users to call the light barrier functionality and explain its usage in a document.

In conclusion, I think that someone(or me) should do the following jobs:

* Make `asymmetric_light_barrier` public and explain its usage.
* In the document of `protect_raw`, suggest an example using with `asymmetric_light_barrier`.

Start by locating HazardPointer::protect_raw and the internal asymmetric_light_barrier implementation, then review how the existing light barrier synchronizes reading and reclaiming threads. Make the barrier available to users and update the protect_raw documentation with the requested usage guidance; done means both the public API and its documented example cover this validation pattern.

Written by the indexing model from the issue text.