CWL SDK: Do not hard-code default storage class in command-line tool
For arvados-cwl-runner, the options --storage-classes and
--intermediate-storage-classes used the hard-coded string `"default"`
internally as the stand-in for the storage class when none was given
when the tool was invoked.
This works when the storage class named "default" is the only default
storage class configured (i.e. with `Default: True` property). However,
this could be confusing, because, for example, there can be more than
one default storage classes in addition to the one _named_ "default".
Furthermore, the it's possible that the class named "default" may not
have the `Default: True` property (although the latter is certainly not
recommended).
By using the empty string, instead of the hard-coded "default", to
indicate that "no valid storage class is explicitly specified", testing
for the condition "we should use default storage classes" is actually
simplified, because the empty string is not ambiguous.
With this change, the decision about default intermediate storage
classes is made when container is requested. This can be beneficial, for
example, when the stages are run on different clusters with different
storage class configurations.
In addition, like in
8cb5ef17 (for Python SDK), the input option value
(comma-separated list of storage classes) is subjected to more robust
validation, to filter out any duplicate or empty values.
Arvados-DCO-1.1-Signed-off-by: Zoë Ma <zoe.ma@curii.com>