JCLOUDS-624 - Fixed bug in ListNodes

Details can be found at: https://issues.apache.org/jira/browse/JCLOUDS-624

Any suggestions are very welcome!

To fix this bug, I used the approach debated in the above link: create
new methods to do the operation using an ExecutorService provided by the
user.The the old methods are still working, but now the operations in
these methods are not concurrent anymore!
There are already things the end users must know about jclouds-chef: when should they use the ChefService or the ChefApi? There's no easy way to implement that "rich list" operation directly in the Chef API (response parsers or transformers, which are the current mechanisms jclouds provides don't seem appropriate to me), and that's why it was initially implemented in the ChefService, but that means users already have to know what class to use.

This is not ideal, but having said this, I like your proposed approach. Not because it encapsulates the use of an executor in a more generic options class, but because it will allow us to cleanup the ChefService interface. I think executors as a parameter are OK for the strategies (they are specific implementations of something), but getting rid of them in the ChefService seems like a good idea.

The problem is that it is a breaker change. If we're going to remove the methods in the next release, is it worth the change?