Options DSL doesn't handle type spec using a set as expected

For a task I'm currently writing I tried to specify the parameter type as `#{kw regex}` expecting it to be a set that can contain keywords and/or regexps.

I did a quick experiment by replacing `assert-type` (https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/cli.clj#L65) with the following:

```
(declare assert-type)

(defn- assert-any-type [types arg]
(some #(assert-type % arg) types))

(defn- assert-type [type args]
(cond
(symbol? type) ((assert-atom type) args)
(set? type) (map (partial assert-any-type type) args)
:else (every? identity (mapv assert-type type args))))
```

Which seems to work but now I'm actually unsure if this is the correct interpretation. The type specification of `#{kw regex}` could also be interpreted as a single parameter that can be a keyword or a regexp.

The wiki only states `Options can also be declared as collections of these primitive types. Sets, maps, and vectors are supported.` but doesn't specify the semantics.

In any case - and if I'm reading the code correctly - the current implementation (see https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/cli.clj#L68) doesn't make sense for a type specification like `#{kw regex}` as it checks each parameter in the order it pulls the types out of the set. (similar for maps?)

Is this a case where the task should specify the parameter more generic as `edn` or `code` and handle type checking itself?

Start with assert-type and assert-any-type in boot/core/src/boot/cli.clj around lines 65-68, then read the wiki's collection type documentation. Resolve the intended semantics for set and map type specifications with maintainers, and document and implement the agreed behavior consistently.

Written by the indexing model from the issue text.