Add NetworkBuilderConfig as part of bundle manifest

[ansoncfit]

Configuration options for bundles could help address a number of outstanding issues:

• Make patterns using parent stations, not stops #114
• transfers.txt should override BOARD_SLACK_SECONDS and OSM walk distance #641
• Option to disallow walking on street when separate sidewalks present #643
• Overriding the default SpeedConfig values
• Handling left-hand-drive regions
• Serializing non-walk linkages/egress tables
• Saving GTFS shapes

It might be worth the effort to allow some of these options to be set in analysis requests, but it's probably sufficient for at least some of them to be set once at the network level.

But note that "network bundle creation" (on the backend) is not the same as network building (on workers). It's not enough to specify assumptions about streets when uploading OSM -- those assumptions need to be saved somewhere and passed along to the worker that actually builds the network.

One idea is to save a new NetworkBuilderConfig in the bundle manifest json saved to S3. With that approach, we would no longer rely on passing a default TNBuilderConfig in TransportNetwork.fromFiles().

At first glance, a TNBuilderConfig file is read when building a network...

r5/src/main/java/com/conveyal/r5/transit/TransportNetwork.java

Line 209 in bc69f80

builderConfig = loadJson(new File(directory, BUILDER_CONFIG_FILENAME));

But in practice, we don't provide that config file, so R5 reverts to the default in this block...

r5/src/main/java/com/conveyal/r5/transit/TransportNetwork.java

Lines 254 to 256 in bc69f80

	} catch (FileNotFoundException ex) {
	LOG.info("File '{}' is not present. Using default configuration.", file);
	return TNBuilderConfig.defaultConfig();

This current implementation seems subpar, and many of the fields in TNBuilderConfig are for old point-to-point routing instead of analysis.

We could strip out the fallback to a default config, and instead throw an exception if a bundle manifest does not have the config. There's not a backwards compatibility concern, because old workers will continue to have the fallback.

[ansoncfit]

The configuration options at hand could just be in the top level object, rather than in a nested config within the manifest. And actually this flat top-level object would be a networkBuildConfig rather than a manifest. We can safely eliminate the concept of bundle manifests; in storage, these are just [networkId].json without the terms bundle or manifest hardcoded.

[ansoncfit]

Just discussed the idea of allowing network .dat files to be rewritten -- it might be useful for people to be able to save car egress tables, for example, after they have built a network. But there's a lot to consider here, about workers that might already be running etc.