Add JSON schemas for plate and well specification

[sbesson]

Similarly to what has been done for multiscales, this PR introduced four new JSON schemas to the 0.4 specification:

• plate.schema which should enforce the mandatory properties (MUST) of the plate specification
• strict_plate.schema which extends plate.schema and enforces the recommended properties (SHOULD).
• well.schema which should enforce the mandatory properties (MUST) of the well specification
• strict_well.schema which extends well.schema and enforces the recommended properties (SHOULD).

Tests formatted using the JSON schema test suite layout are added and the example snippets are extracted under examples using the similar logic as #118.

Two modifications of the validation tests were required. e49f126 ensures only the examples located in the same folder as .config.json are tested against a given schema. 949a352 creates a shared schema store. Since the strict schemas are referencing other schemas via $ref, this store is required to allow the test the local versions under /schemas. Otherwise, the tests will try to resolve remote schemas which would fail either if working offline or when working with unpublished schemas.

The specification of the JSON schema required a few assumptions that are currently underspecified:

• rows, columns and wells are the only mandatory properties of plate
• name and version are recommended properties of plate
• all other top-level plateproperties are optional
• the id of each element of the acquisitions array is an integer
• starttime and endtime of each element of the acquisitions array is an integer
  -version is a recommended property of well

Probably the biggest inconsistency identified by this schema work is about the type of acquisition.starttime and acquisition.endtime which is marked as "epoch string" in the specification text while the JSON examples use integers.

[melissalinkert]

Minor comments aside, this all looks fine to me.

[sbesson]

👍 30d0156 should ensure that id, starttime and endtime cannot be negative and 38c3eb2 shoud clarify the description of the timestamps

[joshmoore]

LGTM.

I assume you want to capture any changes/clarifications to the text in follow ups, no?

[sbesson]

If we are all fine with the current state, next todos were:

1- update the text of the plate and well sections accordingly
2- port the same set of changes (JSON schemas, tests & specification) to latest

Doing this as separate follow-up PRs has the benefit of iterating quicker.