SLING-12376 : Use per thread resource resolver for disposable callbacks
Instead of using different approaches (request attribute and phantom reference queue), we can use the thread resource resolver and store the disposables in the properties map of the resource resolver. When the resource resolver is closed, it closes all Closeable objects in the properties map With that we can remove the different cases, queue handling, and scheduling.
In addition I removed the anti pattern of registering services during activate
what happens if sling models is used outside a request context, e.g. in a background job with a resource resolver created via getServiceResourceResolver?
Then this code blows up with a NullPointerException...the same is true when using an administrative resource resolver
it's a valid use case, although probably rare, to use sling models outside a request...
not disagreeing, lets see if we can come up with something that is better than the previous solution
