Add internal_queue

[TonalidadeHidrica]

No tests, no checks.

[MiSawa]

Why we use i32 as the index type?
It'd probably more natural and convinient to use usize as other Rust standard libraries.

[MiSawa]

Why we want T to be Copy? It seems to me that passing T itself instead of reference &T in push is more natural.

[TonalidadeHidrica]

Because it was what the original code did. But yes, it's so unnatural and complicated to write in Rust, so I'll fix it.

[statiolake]

I think removing Copy is better in the normal Rust libraries, but considering this is a internal code and is only used in the implementation of the maxflow algorithm (only for integer and pair of integers), I also think we can restrict the level of abstraction. Original C++ implementation are not using move semantics, either. For more general purposes we should use VecDeque in my opinion. At least it doesn't have enough interface to use with non-Copy type, e.g. no way to get the ownership of the queued value back.
As an alternative, we can use T directly instead of using references &T if T: Copy to make it more natural.

[statiolake]

Sorry for late response....

[TonalidadeHidrica]

I see. At least I changed &T to T in push method. Also it seemed that removing T: Copy does not do any harm, so I simply removed it for now.

[TonalidadeHidrica]

I used i32 instead of usize in favor of the original code, but I agree that this is not idiomatic in Rust. However, if we are to replace some of them, we have to now decide to what extent we have to replace them. For now, I'll follow every comments on pull request, but I will not make any modification for the first time I create a new pull request.

[TonalidadeHidrica]

I changed my mind and use usize from beginning in some places.

[TonalidadeHidrica]

I added boundary check in pop function, but wondering if this is a good idea from the viewpoint of performance. After all, this structure is only used internally.