[JBWS-3838] Predefined configuration handlers executing in different order when server is restarted

You can count on the order of operations, so this is ok in terms of it being an improvement on the existing code. So I'm ok with it.

Where it breaks down is that if a handler is added post-boot, there is no way for the user to specify a position for it other than last in the list. But that's a problem with the existing code, and isn't a reason not to implement a workaround to an immediate problem like this.

This, and other things like it, are also going to be an issue for the work @aloubyansky is doing on persisting to a filesystem tree instead of an xml document. Ordering information, if relevant, is going to need to be accessible in a generic way to that persistence code so it can write it in the FS for use on boot. It won't be encoded as part of a document structure the way it is now with xml. But that also is a problem we need to sort in general and isn't a reason not to merge this as a workaround for an immediate problem.

So, I'm fine with this change.

For both the issues I described above, I believe the better solution is to not use child resources for these handlers. The parent resource can just maintain an attribute with a complex type (ModelType.LIST with list elements of ModelType.OBJECT, fields in the object being the configType, configName and handlerClass).

We had a movement away from using complex attributes like that going on for quite a while, which IMHO was a major, major mistake. Particularly for cases like this where the complex attribute isn't all that complex.

All that said, I'm not advocating a change to a complex attribute right now. Doing that will introduce a compatibility problem. One that can be handled, but still, it's work. If Alexey's work means we end up with another general mechanism for recording order information and making it available, perhaps it will be less work to make use of that instead of changing to a complex attribute.