feat: runtime validation

[sarahdayan]

In #138 we brought up the idea of adding a runtime validation step to verify invariants. This PR introduces one using invariant, a mirror of what Facebook uses within React.

N.B.: The React invariant module has changed since then, they also provide links to an error decoder on their site which returns the actual invariant message. I think we're okay with the generic message for now since we don't have that many invariants. We can look into it later on if we think this is an actual problem.

Summary

Instead of throwing within components when a configuration option isn't properly set, we now check them all right before running the application, via a validateConfig function. This function takes the configuration object and a set of rules. The rules are grouped within an object which keys are the top-level name of the option, and which value is an object that implements two methods: validate and errorMessage.

The validate method takes the value of the option, method performs an assertion, and returns an object that contains two properties: valid, which is the result of the assertion, and context, for returning extra information about the assertion (useful for error messages).

The errorMessage method takes a context, and returns an error message.

The validateConfig function iterates through the configuration and checks each against their rule, and throws using invariant when there's a violation.

Here's an example of what it looks like in development mode, when passing an invalid type to one of the refinements:

In production, we want to trim away as many bytes as we can, so we strip away these specific messages and return a generic error message instead.

Next steps

Once we have a more broken down documentation with short links (as brought up in #139) we can add links to the development errors for even better DX.

[francoischalifour]

Really cool!