WIP: More work on schemas

Copied from #76:

Both !55 (merged) and !65 showed that there were places to improve the schema. This issue expands on those MRs' work by using the v6/v7 json schema features (where appropriate) and adding tests to complicated parts of the schema. Right now I know of a couple of things that need to be done:

• Use the const schema keyword instead of the enum with only one choice. This issue is documented in the schema, e.g. in beat.core/beat/core/schema/algorithm/3.json:

115-        "type": {
116:          "$comment": "Change enum to const when tools allow v6 json schema",
117-          "type": "string",
118-          "enum": ["loop_user"]
119-        }
--
144-        "type": {
145:          "$comment": "Change enum to const when tools allow v6 json schema",
146-          "type": "string",
147-          "enum": ["loop"]
148-        }

• Specify JSON Schema Draft v.7 (versus Draft v.4)
• Use the if/then/else keywords from json schema v7 to represent more complex logic (e.g. the changes to algorithm parameters in !65)
• As found in !65, there are parts of the schema that aren't tested thoroughly. This is nebulous issue, however, so @flavio.tarsetti @samuel.gaist could you maybe specify what I should do here, so I don't go off the rails?
• Analyse, consolidate, and normalise ASCII character constraints in names across the schema, (see the issue with the dash character)
• Use the correct integer json schema keyword to denote integer type constraints
• Require the uniqueItems: true constraint in objects where arbitrary user-defined keys are accepted (see comments for more info)

(As other issues are isolated, I'll add them to the list)

Closes #76