Fixes the problem of multiple tokens for identical URL patterns

[ubuntolog]

I have recently come across a very strange problem while using SetAccessToken port command. From my application I was updating an access token, however, IGV kept using the old token. The problem could not be reproduced consistently. Fortunately, I was able to track it down to accessTokens HashMap. The variable uses a Pattern object as a key, which allows to have an arbitrary number of identical URL patterns for different tokens (still valid and already expired ones). Since HashMap is not sorted, sometimes it may return correct tokens, but very often it will give you expired ones. Expired tokens are stored indefinitely and are not overwritten by the new ones.
This pull request offers a solution to the described problem by introducing another HashMap and by storing the Pattern object as a value.

[jrobinso]

Thanks for the report and PR. I would like to propose a different solution, using a LIFO queue, see #1453. The use of a map here as a container for pairs was never really appropriate. The alternate PR leaves the stale access tokens in the queue, they could be removed with a bit more coding, but they should never be accessed.

[ubuntolog]

Your solution seems to be a more elegant alternative. According to the documentation (I never used Deque), it should do the job. A queue is a better data structure for this task, code is more readable, and we do not need an extra variable. I will test it locally and let you know, if I find problems. Thank you

[ubuntolog]

Changes from #1453 seem to work as expected.