Allow constructing model for page other than `currentPage`

### **Is your feature request related to a problem? Please describe.**
A `Page` model for a page other than the current requested page can not be constructed using the model factory because the page injected into the model is `currentPage`.

The `currentPage` remains the original user-requested page even if the resource being used to construct the model is from a different page.

This leads to inconsistencies in the page model if you try to construct the page model for a different page, because (inside the page model implementation) `currentPage.getContentResource()` is not the same as `request.getResource()`, which leads to some methods returning information relating to the page you are requesting the model for, while other methods always return information about the page that was originally requested by the user - depending on if the method relies on the `this.currentPage` object or the request resource.

Being able to reliably construct models for pages other than the originally requested page would be beneficial because it would allow custom models to get information (provided in the `Page` model) about other pages without having to re-implement the logic contained within the page model.

----

### **Describe the solution you'd like**
In V1 Page Model Implementation Change:
```
@ScriptVariable
protected com.day.cq.wcm.api.Page currentPage;
```
to
```
@ScriptVariable(name = "resourcePage")
protected com.day.cq.wcm.api.Page currentPage;
```

I'm not entirely sure if this would have impacts on any current existing behaviour.
In my limited testing it appears to work fine, and it seems like it should be OK because currently the `Page` model is never used in a situation where `currentPage` and `resourcePage` are different (thus the feature request).

----

### **Are there alternatives?**
Nothing reasonable.

Start with the V1 Page Model Implementation Change and locate the Page model's @ScriptVariable currentPage injection. Compare the currentPage and resourcePage contexts, then check existing model tests or usages for behavior when they differ. Done means models can be constructed for another page without changing existing current-page behavior.

Written by the indexing model from the issue text.