added iter method to stack and queue

[RaviMohan]

which returns an array with Stack elements in LIFO order/Queue elements in FIFO order.

This is essentially the fix for #116

This PR only adds the iter method with LIFO semantics for Stack and FIFO semantics for queue.

The Stacks and Queues are still parametrized by the underlying container (Deque{T}) than the element type. I think these datastructures should ideally be parametrlized by the element type, and not implementation details which causes an abstraction leak.

However I have not changed this in this PR's code, only added an iter method which returns an array with the elements in an order that makes sense for the datastructure - LIFO for Stack and FIFO for queue. I finally went with @lindahua 's concept than by implementing next() etc because this makes it easier to add alternate traversal schemes later.

[lindahua]

The practice of parameterizing stacks and queues by underlying containers instead of elements are following C++ STL, where they are considered as container adapters (see http://en.cppreference.com/w/cpp/container/stack).

[kmsquire]

Dahua, do plan to add any other backends? If not, or even if so, simplifying printing in show might be worthwhile to address that concern.

(I really wish we had better separation between the representation and printing forms of types, ala Python.)

[RaviMohan]

Thank you for the reference.

If "STL Like" is the underlying design intent, then (imo) we should be able to to actually parametrize the datastructure by multiple container types (as you can do in STL where a stack can use Deque,List and Vector as the underlying container- iirc - it has been a long time since I wrote any C++, I could be wrong).

The code seems to read as if only Dequeues can be used right now. I could be wrong and maybe we could parametrize by container type right now(which is great, if true, but it would be great to document that somewhere) .

I don't quite grok the Julia type system and how to express signatures yet. Maybe we could just add some documentation to these types mentioning the possible containers that Stacks and Queues can be parametrized with, both right now and future plans if any.

As I said above, this doesn't affect the PR.

Thanks again.

[kmsquire]

Looking back at this: the fact that the current implementation copies the array instead of iterating over the existing array probably isn't what @lindahua had in mind. It would be better to take a cue from the Iterators.jl package (and Julia's built-in iterator types) and create a custom type for each iterator.