Improve .create-api.yml loading to understand single values or booleans for set/array options

[liamnichols]

• Simplify Entity-type and Mutable Properties in Config #100

When deserialising the yaml or json configuration options, we're decoding into the types defined on the properties within ConfigOptions. This means that on sets an arrays, you must define an array in json or yaml even if there is only one item. For example:

entities:
  mutableProperties: [classes]

or

entities:
  mutableProperties: 
  - classes

While this isn't a huge deal, we could be a bit more lenient here. And that's what this change does. When the type is a Set or an Array, it'll also attempt to decode the property as a single value and if its present, it'll wrap it in a collection and return it.

It allows the user to simplify their configuration like so:

entities:
  mutableProperties: classes # or [classes], it doesn't matter now

It makes the config file a bit more readable.

In addition, I also wanted to go one step further for cases where the value within the Set/Array is a fixed set of options. In this case, we can annotate them as CaseIterable which will also allow us to represent the value using booleans. true being Option.allCases and false being [].

For example:

entities:
  mutableProperties: true # or [classes, structs]

The above will be parsed as [.classes, .structs] and the result will be that we generate all properties as mutable regardless of type (exactly what you would expect from setting mutableProperties to true).

You can do the inverse as well:

entities:
  mutableProperties: false # or []

Which reads "no mutable properties" and like you expect, the object decoded value is [], which would result in everything being let.