ConsoleInput

The ConsolInputHandler was constantly creating empty Strings thus imposing unnecessary activity on the heap. A 1,5 hour run showed 7% of all the bytes allocated on the heap were coming from Thread-5 (in this case running the static ConsoleInputHandler::run)

While a static runner for this is fine I've give it a proper thread name as well now.
As are reading the console with readlLine() we are not required to sleep the thread as readLine() is already blocking until the line has completed either via \n or \r or by EOF there is no explicit need to sleep again.

One could think about move the ConsoleInputHandler as well on the ExecutorService. (I'm happy to follow up on this either via this PR or a new one if you'd like)

As I was already investigating the ConsoleInput I've taken the liberty to rearrange some of the InputEventHandlers flow allowing for earlier returns thus saving some branch checks

About Threading in PhantomBot

As I've been looking at profilers and dumps over the last weeks and I noticed the thread naming scheme is a little hit or miss in PB. Thus this PR already starts by defining a default name for the ExecutionService's Threads

In general one can see some tasks/runners using the ExecutionService and setting a thread name. Setting a thread name is rather pointless as the thread will also run a plethora of other tasks.
As named threads only makes sense for static threads, my recommendation here is to remove this thread naming in itself for tasks running on the ExecutionService or at the very least revert it once the task has completed (mind you this comes with an overhead). The same is true for JSTimer which set thread names only valid briefly.

Let me know what you prever and I am happy to implement it

Some minor thing
I've also added some additional threadsafety for JSTimer