This `ScheduledAction` class existed before, but while reviewing this code along with these changes, I think we can do far better. 

The result of this design and these changes is that a scheduled task will end up with `ScheduledAction`, a `CompositeSubscription`, then the `Subscription` from the `Future`, then either a `Dequeuer` or a `Remover` depending on whether it is immediately scheduled or delayed. The `Removed` has yet another `CompositeSubscription` within it. 

This means we can have 2 `CompositeSubscription`s and at least 3 `Subscription` wrappers for every single `onNext` going through an `observeOn` operator. This is crazy object allocation.

The cost of having `SubscriptionQueue` as an external, generic data structure is that we end up wrapping things yet again, and that is very costly here. 

Both the `addParent` and `createDequeue` logic can instead be replaced with a single static function that knows how to remove itself, but does not need allocation per `ScheduledAction`.

There was a simple variant of this design several commits ago that got lost in another refactor, and we're straying farther away and adding more allocations.

Note how it was created once for the entire `Worker` instead of per `ScheduledAction`: https://github.com/Netflix/RxJava/blob/3759b0eda798d1d1c7a577ec3bc74582f2194c4a/rxjava-core/src/main/java/rx/schedulers/EventLoopsScheduler.java#L62 

We can go further and stop using `Subscriptions.from(Future)` (yet another wrapping) and within the `Scheduler` implementation correctly close over everything we need just once. We must allocate a single `Subscription` that we return to the user, but within that we can reference everything we need:

- the Future to cancel
- the `CompositeSubscription` or `SubscriptionQueue` to remove ourselves from

This will likely mean less code reuse, but that's what happens when we start doing performance optimizations, and deep inside these `Scheduler` and `Subscription` implementations, that's the price we'll pay for performance.

For example:

```java
            ScheduledAction s = poolWorker.scheduleActual(action, 0, null);
            directTasks.add(s);
            s.add(directTasks.createDequeuer(s));
```

That is nice and brief right now, but represents a wrapped `Future`, a `Subscription` wrapper with a `CompositeSubscription`, adding to a queue, creating another `Subscription`, adding to a `Map`.

Instead, let's go direct to the `Executor`, get the `Future`, return a single `Subscription` that does not have a `CompositeSubscription` in it, and add to a single highly-tuned queue.