class PageRequest

At the high level the goal of the objects here is to

1. Trigger external entities to do work based on VMO operations, such as asking a pager to supply

a missing page of data.

2. Have a way for external entities to let the VMO system know these requests have been

fulfilled.

3. Provide a way for the high level caller, who may not know what actions are being performed on

what entities, to wait until their operation can be completed.

The different objects can be summarized as:

* PageRequest: Caller allocated object that the caller uses to perform the Wait.

* PageRequestInterface: A reference to an object implementing this interface is held by the

PageRequest and provides a way for the PageRequest to interact with the underlying PageSource.

* PageSource: Performs request and overlap tracking, forwarding unique ranges of requests to the

underlying PageProvider.

* PageProvider: Asynchronously performs requests. Requests are completed by actions being

performed on the VMO.

A typical flow would be

* User allocates PageRequest on the stack, and passes it in to some VMO operation

* VMO code needs something to happen and calls a PageSource method, passing in PageRequest it

had been given.

* PageSource populates fields of the PageRequest and adds it to the list of requests it is

tracking, and determines how this request overlaps with any others. Based on overlap, it may

or may not notify the underlying PageProvider that some work needs to be done (the page

provider will complete this asynchronously somehow).

* VMO returns ZX_ERR_SHOULD_WAIT and then the top level calls PageRequest::Wait

* PageRequest::Wait uses the PageRequestInterface to ask the underlying PageSource how to Wait

for the operation to complete

# As an optional path, if the PageRequest was not Waited on for some reason, the PageRequest

will also use the PageRequestInterface to inform the PageSource that this request is no longer

needed and can be canceled.

For the other side, while the Wait is happening some other thread will

* Call a VMO operation, such as VmObject::SupplyPages

* VMO will perform the operation, and then let the PageSource know by the corresponding

interface method, such as OnPagesSupplied.

* PageSource will update request tracking, and notify any PageRequests that were waiting and can

be woken up.

There is more complexity of implementation and API, largely to handle the fact that the

PageRequest serves as the allocation of all data needed for all parties. Therefore every layer

needs to be told when requests are coming and going to ensure they update any lists and do not

refer to out of scope stack variables.