Add built-in support for pagination

[jboarman]

To get the initial set of 100 pharmacies, we could use the following request:

/nearest/100/pharmacies/to/75001  (1st page)

For this issue, we could add support for getting the next 100 with the following:

/nearest/100/pharmacies/to/75001/skipping/100  (2nd page)
/nearest/100/pharmacies/to/75001/skipping/200  (3rd page)

APIs today often offer continuation tokens that consider changes in the underlying data. As it is now, the underlying data is expected to remain reasonably static. So the benefits of a more complicated approach are not yet warranted and remains to be something that can be added at a later time when needed.

As the REST API gets more elaborate, we may want to handle all parsing of the query path ourselves instead of relying on FastAPI routes.

[jboarman]

@bvdalling suggested /offset/ as another naming approach. I'm not sure which naming approach is more clear or common.