Add design data for debug builds (and optionally production monitoring)

## Motivation

I want to be able to develop without connection to online data sources. I often use this to:

* Develop without internet access (such as in a park).
* Code against a server that I have not yet published.
* Code against server changes that aren't live.
* Test front-end and server separately yet ensure they remain in sync.
* Have front-end created first by a designer, who specifies what they need with design data, then move the loading of that data to the server after they finish iterating their data needs.

All of these are a lot easier if I can use design data for each request the client makes.

## Specific request

Change routes.json from supporting:

```json
{
"path": "/",
"page": "./pages/home",
"chunk": "main",
"data": {
"articles": "GET https://gist.githubusercontent.com/koistya/a32919e847531320675764e7308b796a/raw/articles.json"
}
}
```

to:

```json
{
"path": "/",
"page": "./pages/home",
"chunk": "main",
"data": {
"articles": {
"method": "GET",
"url": "https://gist.githubusercontent.com/koistya/a32919e847531320675764e7308b796a/raw/articles.json",
"design-data": "articles.json"
}
}
}
```

This references a file, `/design-data/articles.json` which is built into a second webpack chunk (named `design-data`). `articles.json` would contain an example of what could be returned by the url.

When the data is requested, the router would always fulfill it based on the mode the app is running in:

* **debug**: always use the design data. Don't even attempt to connect to the url.
* **release**: always use the url.

The design-data would be built as a dynamic, named chunk. Because release mode never requests it, it can be built and served (and used for production monitors, see below) without adding any weight to the client-side downloads.

## Optional extra credit

Create a test generator that iterates routes.json and outputs a series of tests for the server data sources. These can be used both as coding-time acceptance / integration tests (things most people put in the unit test suite) and as run-time production monitoring (especially useful when working with APIs I don't control).

Each test would consist of fetching the url, loading the design data, and verifying that the two have compatible structure. The structure is compatible if:

* Given an object in the design data, the url gives an object with at least every field listened, and each field's value is compatible.
* Given an array in the design data, each element in the design array is compatible with the first element, and each element in the url data's array is compatible with the first element in the design data.
* Given a value in the design data, the server's value is of the same JSON type as the design data's.

This definition of compatibility is extensible. If, for example, the application has defined a specific format for passing datetimes or durations, then we can extend the value recognizer to distinguish those from strings in the design data and expect the same format for the url data.

Start by locating routes.json and the router that fulfills its data requests, then trace how webpack chunks are configured. The requested design-data chunk should provide responses in debug mode while release mode uses the URL; the optional work would generate compatibility tests for those sources.

Written by the indexing model from the issue text.