Explicit type name/syntax for byte arrays
At the moment, the KS byte array type has no type name - byte array fields can only be created by specifiying `size` (or `size-eos: true`) with no `type`, in which case the field implicitly becomes a byte array.

In most cases this is fine - the `size`/`size-eos` declaration indicates that the field is a byte array. However, it creates problems in combination with `switch-on`: the only way to have a byte array type as a `switch-on` case is by adding `size`/`size-eos` on the switched field and having no explicit default case under `cases`, so that the implicit default case becomes the byte array type. This is suboptimal for multiple reasons:

* It's impossible to have a byte array type as anything other than the default case. For example, when switching a field type on an integer `i`, it is impossible to have the field parsed as a byte array only if `i == 1` and as a different (named) type in all other cases.
* The behavior is not very obvious when reading the spec. Because a byte array type in `cases` *must* be set implicitly, there is no visible indication that the byte array case is possible, so it's easy to overlook that this case exists.

Both of these issues could be solved by adding a type name for the byte array type, which would allow explicitly declaring `switch-on` cases for the byte array type.

There is also the related problem that there is no way to set `size`/`size-eos` only for the byte array case. Because there is no way to add extra attributes to a single `switch-on` case, `size`/`size-eos` must be set on the entire field, which creates a substream for all non-byte-array cases and (usually) changes how they are parsed. This problem *isn't* solved by adding a byte array type name. However it is very similar to the problem described in #790, and some possible solutions have already been suggested there.

All of these limitations can be worked around by writing an extra wrapper type that has a single byte array field of the required size. This effectively gives a name to that particular variant of the byte array type. This solution isn't very convenient though, and it also makes the API of the KSY and the generated code more complex than necessary, because you now need to go through an extra field to access the actual byte array.