Minor change to hopefully reduce the array copies needed as we build these stack strings
Change the new-line in threadly to be represented on a platform specific way
This adds a small utility class "StringUtils" to make this easier, and reduce duplication for a few things
Fix for a found bug with recurring tasks on the NoThreadScheduler/SingleThreadScheduler
If you have a recurring task with zero delay (so it just keeps running over and over again), it would inject itself ahead of any .execute() runnables provided before the recurring task would complete.  This was due to the fact that we were attempting to avoid two reposition calls by repositioning the recurring task at the start rather than the end.  In the PriorityScheuledExecutor this is not an issue, because we reposition to the end, then once done we reposition again.  I would like to avoid that here, since we know that only one task may be running at a time.  So instead we now reposition at the end, but will mark the task as "running" while it is executing so that we know to not include it in calls to check if we have additional tasks to call.
I added a unit test that reproduced this case, and is now passing with this fix.  I also added and improved the javadocs for this change.
Merge pull request #90 from jentfoo/unstable_staging

Fix for a found bug with recurring tasks on the NoThreadScheduler/SingleThreadScheduler
Overriding this function is not necessary
So I droped the visibilty from protected to private, and removed the overriden implementation.
This resolves #91
There is a bit more included in this commit than I originally expected.  This adds "shutdownNow" to the SingleThreadScheduler.  But it also improves the logic for the normal "shutdown" call as well.
Once I wrote unit tests for the SingleThreadScheduler, I added similar unit tests to the PriorityScheduledExecutor unit tests.  This uncovered a couple other small defects/defencies in both the PriorityScheduledExecutor as well as the PrioritySchedulerStatisticTracker.

I will detail things more line by line in the pull request.
There is one key difference between recurring tasks in java.util.concurrent.    ScheduledExecutorService and threadly's interfaces...this fixes the oversight of when a recurring task throws an exception.
This commit solves this in two ways.  The first is to better document threadly's behavior, so it is more obvious how it is different (as I feel threadly's behavior is closer to what most people expect).  The second is to make the wrapper classes that implement ScheduledExecutorService (PriorityScheduledExecutorServiceWrapper / SingleThreadSchedulerServiceWrapper), match the java.util.concurrent behavior (which it already was for scheduleAtFixedRate, just not scheduleWithFixedDelay).  Then the wrapper ScheduledExecutorServiceWrapper's behavior now matches threadly's interface expectations.
I also fixed some small behavior where throwables could be thrown.
Fix a unit test failure on the slow ec2 instance (were not waiting long enough)
Merge branch 'unstable_staging' into more_javadocs+comments
Added more javadocs to protected and private functions.
The goal is to add comments in general to help make it easier for others to follow the code and understand what is going on where.
I cleaned up a few minor things that I saw as I went through the code looking for additional places to add comments.
Merge pull request #92 from jentfoo/issue91_SingleThreadScheduler_shutdownNow

Issue91 SingleThreadScheduler shutdownNow functionality (plus bug fixes)
Merge branch 'more_javadocs' into unstable_staging
Added addListener without an executor to ListenerHelper
Also thought I would be consistent and avoid catching RuntimeException and instead just catch throwable (in case we get an error or something)
2.1.0 release version
Increment versions for 2.2.0-SNAPSHOT
Merge branch 'master' into gradle-2.0_updates