support /api/* routes for programmatic access

## User Story

In order to offer programmatic access to new catalog, datagov wants to support machine-focused routes (e.g. `/api/*`) to query against.

## Acceptance Criteria

[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using [BDD](https://en.wikipedia.org/wiki/Behavior-driven_development#Behavioral_specifications).]

- [ ] GIVEN our catalog is used both via the UI and programmatically \
WHEN a `/api/*` route is queried \
THEN a set of matching records for that entity (e.g. datasets, keywords, locations, organizations) is returned in JSON.

## Background
- we should distinguish between human-focused routes (e.g. `/organization/*` or `/dataset/*`) which are accessed via the UI vs those accessed programmatically. for example, we should probably move all the `/harvest_record/*` routes within the `/api/` route because they're intended to return raw JSON data instead of html.
- `/api/*`routes were added in the spatial filter [feature](https://github.com/GSA/datagov-catalog/pull/97/files) which prompted the creation of this ticket.
- related to [#5565](https://github.com/GSA/data.gov/issues/5565)
- version the api (e.g. `/api/v1/`)

## Security Considerations ([required](https://nvd.nist.gov/800-53/Rev4/control/CM-4))

[comment]: # "Our SSP says 'The Data.gov team ensures security implications are considered as part of the agile requirements refinement process by including a section in the issue template used as a basis for new work.' so please don't remove this section without care."
[Any security concerns that might be implicated in the change. "None" is OK, just be explicit here!]

## Sketch
- highest priority is making datasets queryable via an `/api/*` endpoint.