Change our versions to 2.0.0-SNAPSHOT for the start of a branch for the 2.0.0 release...once we get closer this will be merged into unstable_staging (and then eventually master)
Removed some of the deprecated features for the 2.0.0 release
This is removal for issues: #67 #66 #65
Added the remove Runnable/Callable part of the PrioritySchedulerInterface
This interface is pretty full featured already, so might as well include this functionality.  The few places that were missing it were trivial to add.
Lots of changes!  All things for 2.0.0 due to interface changes
This adds the remove to the interfaces via a new interface 'SchedulerServiceInterface'.  This interface now includes the isShutdown call.

This also changes the NoThreadScheduler.  Now that functionality exists as a "TestableScheduler", and the NoThreadScheduler is designed to be more general use designed (no ability to provide time via tick).  This allows the implementation of the new SingleThreadedScheduler.

In addition there were lots of unit test changes.  Attempting to make things more uniform.  Stop assuming that things are not overriden in classes (in favor of testing them twice in case they change in the future).  This is still not completely uniform, but I think it's better.  I also _tried_ to reduce the code duplication in a few places in the unit tests.

This also fixes a bug in the ContainerHelper where it was not being as agressive in searching as it should have been.
Merge branch 'master' into v2.0.0_staging

Conflicts:
	build.gradle
	build.upload
	pom.xml
Merge pull request #77 from threadly/v2.0.0_staging

Upgrading unstable_staging to be the new 2.0.0 branch (release date TBD)
Rename SingleThreadedScheduler to SingleThreadScheduler, for consistency with NoThreadScheduler
Merge pull request #78 from joshuawarner32/unstable_staging

Rename SingleThreadedScheduler to SingleThreadScheduler, for consistency...
Fix removing tasks from the PrioritySchedulerLimiter

We should not override the remove functions from SchedulerServiceLimiter.  This may prevent us from being able to remove tasks that are currently in the queue.
This changes our unit tests code to hopefully be a lot more maintainable.
I wanted to test all possible cases for the interface, but this was getting a bit hairy to do so.  Because we use a lot of inheritance it would mean when ever we would add a test case for a given interface, we would have to add it in like 8 different places.  This caused a TON of small little functions that just would call into the static implementation of the test.

This changes that by actually making the tests extend each other in a similar structure to how the code does.  We then just have to override a function to provide the actual implementation to be tested.  In some cases we override the test case itself to provide more specific (or further) verification.  This allows us to continue to have good visibility into what tests for what components are failing.  While greatly reducing lots of small little wrapper functions.

The complexity comes in from classes which have unique behavior, or implement multiple interfaces.  The limiters are the greatest example of this.  It requires us to now have a test class per interface test case.  So in the limiters case we have one class that is testing the limiting functionality, and a second one which is testing the general interface functionality (thus doubling the amount of classes to test the limiters).  The TaskExecutorDistributor is another example, now needing a second class to test the implementation of the returned "submitterForKey" functionality.

For that reason I decided to avoid testing the wrappers in PriorityScheduledExecutor and PrioritySchedulerStatisticTracker, since those just depend on the PrioritySchedulerWrapper (which is already well tested).  Otherwise those two would have required two additional classes.

All in all, I think this makes the unit tests code smaller, and more maintainable, but look forward to feedback from the other developers.
This class was extending the wrong interface test
So we previously were not getting coverage on the Service part of the interface.
We need to record the schedule time in this test before we schedule it
Reduced code duplication by creating an abstract class that can be used for creating a "SubmitterExecutorInterface" implementation.
This reduces code now, but will be more useful in the future.
Merge pull request #80 from jentfoo/master

Reduced code duplication by creating an abstract class that can be used for SubmiterExecutor's
Merge pull request #79 from jentfoo/v2.0.0-unit_test_cleanup

This changes our unit tests code to hopefully be a lot more maintainable
Merge branch 'master' into unstable_staging
Were not checking if the SingleThreadScheduler was shutdown before accepting new tasks
This fixes that, as well as adds a unit test to verify the behavior
Couple unit test fixes/improvements
These have already been fixed in the 2.0.0 branch I believe, but since we don't know when that will be released, these are for 1.3.0
Merge branch 'master' into unstable_staging

Conflicts:
	src/test/java/org/threadly/concurrent/PriorityScheduledExecutorTest.java
	src/test/java/org/threadly/concurrent/PrioritySchedulerStatisticTrackerTest.java
Small unit test improvements to get a little more code coverage