Rename TimerTask and related methods

Rename cancelTimer to cancelTimerTask to clarify usage.
There is already an actual Timer object named cancelTimer in Driver.
Also rename the killTimer() method in AbstractJdbc2Statement to killTimerTask() to clarify it's usage.
Change TimerTask methods to be called through the Connection

Change all references to addTimerTask(...) and purgeTimerTasks() to go through the Connection object.
This removes any direct references to the TimerTask related methods in Driver from the rest of the driver.
The new addTimerTask(...) and purgeTimerTask() methods in AbstractJdbc2Connection still use the shared static Timer in Driver.
Avoid classloader leak from dangling Timer thread

Previously, when the driver is loaded a static Timer is allocated in the Driver class itself.
That Timer is shared by any TimerTask that gets scheduled (ex: for Statement timeout handling).
If the driver is later unloaded (e.g. in a containerized environment) the Timer thread is never stopped.
Additionally, the Timer thread itself may maintain references to other driver classes that will never get unloaded.

The changed classes now use a SharedTimer that maintains a reference count of requests for Timer.
A Connection requests a Timer via the getTimer() method.
This increments a reference count to keep track of the number of outstanding references.
The Timer reference is marked as returned by calling releaseTimer() in Connection.close().
If there are no outstanding references left, the internal shared Timer object is closed so it's resources can be GCed.

Well behaved JDBC code that calls close() on all Connections should be able to unload the Driver without leaving dangling references.
Merge pull request #197 from sehrope/cl-leak

Fix Timer thread classloader leak
Thanks @sehrope !