Some folks calling NB APIs from Ant tasks loaded using <taskdef> discovered that
they had memory leaks. If org-openide-util.jar is loaded in a special class
loader (such as the Ant class loader) and any code loaded in that loader uses
Utilities.activeReferenceQueue(), a thread is started which never dies for the
lifetime of the VM and holds onto Utilities.ActiveQueue.class and thus the whole
class loader. This happens even if all references sent to that queue have in
fact been collected and there are no more ever added.

Solution is to shut down the thread if as many references have been processed as
were originally enqueued. If more references come in later, can simply restart
the thread, though I don't imagine this would be common in practice.

Unfortunately we cannot check for certain how many references were enqueued, as
the Java API does not permit this. The API design of activeReferenceQueue() is
flawed. The ReferenceQueue itself should never have been exposed; should rather
have exposed e.g.:

public abstract ActiveReference<T> extends WeakReference<T> {
    protected ActiveReference(T object) {
        super(object, activeReferenceQueue);
    }
    protected abstract void disposed();
}

Instead, can just count how many times activeReferenceQueue() is called with
intent to enqueue a reference. OpenGrok confirms that all code in nb.org CVS in
fact does this in the expected way.

Wrote a test and do not see any harm from this patch, but would appreciate
review from Petr and/or Yarda as the logic is a bit subtle.