Improve functionality of the classloader task when applied to the core loader

Revisiting [issue 47003](https://issues.apache.org/bugzilla/show_bug.cgi?id=47003). The original title was *“Add to ant lib classpath from within project file”* which still describes what I'm trying to accomplish here.

With these changes, the core class loader is guaranteed to always be an `AntClassLoader`, so the (still undocumented) `<classloader>` task can be used to add to that without replacing it. One use case is the following: users only have ant core available, but some dependency management tool (e.g. Ivy) provides jar files for optional tasks and their dependencies. Then adding those jars to the core class loader will make those optional tasks available without having to `<taskdef>` each one with the corresponding `<classpath>`. There is an antunit test case demonstrating this, using `<junit>` as an example. This approach can be used for third-party tasks as well, potentially simplifying things a lot. This should in particular help projects which up to now had a dedicated build script (or two, one shell script for *nix and one batch file for Windows) to build the class path resp. library path before invoking ant. Now they can drop those scripts and portably build the class path in ant itself.

Of course it would be useful to also document the `<classloader>` task, and give examples where modifying a non-core loader would be useful, and add antunit tests for that as well. But since I haven't yet figured out those non-core use cases, I'd like to keep that out of this pull request. And I'd welcome input on that.