Refactor Reservation Date Logic

[esoterik]

We need to make sure that there's a single source of date logic for reservations that lives in the Reservations model. #end_date and #overlaps_with? are two examples of methods that do this already, but I don't trust that they're used appropriately everywhere.

In the end, the only time the due_date attribute should be referenced outside of the reservation model is during reservation creation and when reservations are flagged as overdue (essentially, only situations that care about the actual due date, not just when the reservation is no longer actively holding an equipment item). Everywhere else should use an appropriate method on the reservation model.

The motivation behind this is to make #986 easier: in that issue, we need to add a processing date attribute to reservations.

[acelwood]

Should the "due for checkin" date for overdue items be the original due date (in the past) or "today"?

[acelwood]

The cart and cart validations due date is separate from this issue, right? Because the cart is not (yet) a reservation?