Canonical collections

[adamnfish]

This PR replaces #80. The canonical container either comes from the FrontJson, or is the first container on the front.

Note that this PR contains two commits, the second specifies the edition network fronts' canonical containers as well. While we wait for the tools to support this feature, the network front canonical containers can be hard-coded. This commit can be rolled back when the tools support is in place and the correct JSON is actually coming through.

Don't merge this yet, it's open for comment/review, I'm going to test it by integrating it with MAPI.

Note that I'm assured there can never be a front with 0 containers. I've raised a an issue (#83) suggesting we capture this by making that a NonEmptyList. That would remove the need for the "no collections" fallback string.

[adamnfish]

Question: What happens if the editorially chosen canonical collection isn't actually on the front? This shouldn't be possible at the tools level, but is a totally reasonable edge case when caching etc is taken into account.

Should it silently fall back to the top container (which might break things downstream)? Leave the front with no canonical container (which will break things downstream)? Throw an exception?

Maybe it needs to be an Option because of this, but that raises lots more variants of this problem in lots more places.

Thoughts @janua @stephanfowler?

[adamnfish]

p.s. This problem is happens at the moment on CODE because the uk, us, au paths don't contain the hard-coded collection IDs, annoyingly. Clearly that's a bug in my hard-coded "waiting for tools" workaround but the question above is relevant to the solution to this bug.

[janua]

@adamnfish I think we should fallback, as that is the current behaviour; a reliable fallback consistent in code.
I think we should do both. Make it Option but also have a method of getting the solid underlying type without the Option.

[janua]

👍