Add method to close and unregister a database connection [DRAFT 1]

[Maxr1998]

This is my first draft that would close #523, the only issue I currently see is when you'd add the same TransactionManager for multiple databases and then removed it (it remove the first occurrence from the List, but not necessarily the right one); or register another TransactionManager for the same database, basically creating a "dead" manager inside the list, this issue should be easily fixable though.

Looking forward to your opinions on my PR.

[Tapac]

Is it really necessary to add deque instead of a simple @Synchronized and setting NotInitializedManager to _manager when the last manager was unregistered?

[Maxr1998]

Good question. I thought it'd make sense to revert to the previous TransactionManager explicitly, but we could also ofc reset it to NotInitializedManager. What do you think?

[Tapac]

I missed the point that you were trying to restore the previous manager and now I think that it was a bad advise to set NotInitializedManager. Maybe it's better to use any (first?) manager from the registeredDatabases map?

[Maxr1998]

Getting a random element from the registeredDatabases isn't a really pretty solution in my opinion, additionally unintuitive and not well-defined.. We could also add another private volatile var that saves the first TransactionManager, and is set to NotInitializedManager if that one is (finally) removed, however, there might be other TransactionManagers left in the map. So, that solution might also be counter-intuitive for users of the library.

I fear there's not really a good way around using the Deque to have the TransactionManagers in a certain order..

[Tapac]

I guess that a deque is not such a bad decision. So I will approve that PR and reject another one.
Thank you.