Remove need to maintain discovery-option ordering separately from the option

The various discovery-option (including the static-discovery variant) are represented as resources, with the ordering between them maintained in the parent /host=*/core-service=discovery-options resources.

This is too troublesome for the non-xml filesystem-based persistence stuff Alexey Loubyansky is working on, and is non-standard in general, as we are striving toward using lists instead of child resources.

I propose the following:

1) The /host=*/core-service=discovery-options "discovery-options" attribute should be converted into LIST of OBJECT from the current LIST of STRING.

If we can come up with a good name for an attribute, we can just add a new one and deprecate the old one, preserving compatibility. But if we do that the old "discovery-options" attribute can't be writable any longer.

2) The elements in the list can be of varied types. This reflects the fact that there are varied types of child resources (discovery-option and static-discovery). In the metadata this will be handled as if a general "discovery-option" type were a complex object with alternative top level fields. For example in the r-r-d output

"discovery-options" => {
  "type" => LIST,
  "value-type" => {
    "static-discovery" => {
      "alternatives" => ["custom-discovery"],
      "type" => OBJECT,
      "value-type" => {
          "protocol" => {...},
          "host" => {...}
          "port" => {...}
      }
    },
    "custom-discovery" => {
      "alternatives" => ["static-discovery"]
      "type" => OBJECT,
      "value-type" => {
        "code" => {...},
        "module" => {...},
        "properties" => {...}
      }
    }
  }
}

3) We should continue to support the existing child resources as a sort of runtime-only (i.e. not directly persisted) alias into an item in the list. The Resource implementation for /host=*/core-service=discovery-options dynamically generates these. The persistence logic completely ignores them.

The problem is the child resource needs a name, while the list elements above really don't. We could require a superfluous "alias" attribute in the list elements, and probably we could generate one if one isn't provided. If an alias isn't provided, the name of the child resource becomes "unaliased-X" where X is the current index in the list. For a given element this could change though if the list changes. If people want a consistent name, provide an alias.

With these non-persistent child resources, we can still support the "add" operation. Invoking it has the result of adding a new element to the list.

The child resources could include an attribute indicating their current list position. This would be read-only (i.e. no trying to reorder the list by changing this) but perhaps the "add" op could accept it as a param to indicate the initial position in the list.