Device types in JSON schemas are non-standard

[callumforrester]

See the following example JSON snippet from the /plans endpoint:

{
  "name": "count",
  "description": "Reads from a number of devices.\n    Wraps bluesky.plans.count(det, num, delay, md=metadata) exposing only serializable\n    parameters and metadata.",
  "parameter_schema": {
    "additionalProperties": false,
    "properties": {
      "detectors": {
        "items": {
          "enum": [
            "sample_stage",
            "sample_det",
            "oav",
            "synchrotron",
            "panda"
          ],
          "type": "bluesky.protocols.Readable"
        },
        "title": "Detectors",
        "type": "array",
        "uniqueItems": true
      },
...

The detector type is listed as "bluesky.protocols.Readable", JSONForms does not seem to be compatible with arbitrary types in this way. See the following error:

Uncaught Error: schema is invalid: data/properties/detectors/items/type must be equal to one of the allowed values, data/properties/detectors/items/type must be array, data/properties/detectors/items/type must match a schema in anyOf, data/properties/detectors/items must be array, data/properties/detectors/items must match a schema in anyOf

When I change the type to "string" I get a form rendered.

@tpoliaw suggested moving the bluesky type to a non-standard field in #522, which may be a good idea given that the current state of affairs requires special casing in any clients.

Acceptance Criteria

• Clients reading plan schemas do not need insider knowledge to determine device parameter types

[callumforrester]

JW: Remove the type field that is returned - the enum already defines what the allowable values are, for now we aren't doing any validation or special handling. We may want to return a type when we have special UI elements, but for now having an unused field that may change is worse than having no field.