Support optional "inplace" iteration for Combinations/Multicombinations

[mjrodgers]

For use cases that benefit, we provide an option to have inplace versions of the iterators for combinations(n,k) and multicombinations(n,k) using an optional inplace keyword.

Closes #4993

[lgoettgens]

So if I understand correctly, the "inplace" kwarg only exists for the case of combinations(::Int, ::Int), and not combinations(::Vector, ::Int), right?
Does it make sense to also allow it in the former case? (Even it does, maybe do that in a future PR).

Could you add the new kwarg to the two respective docstrings?

[mjrodgers]

So if I understand correctly, the "inplace" kwarg only exists for the case of combinations(::Int, ::Int), and not combinations(::Vector, ::Int), right? Does it make sense to also allow it in the former case? (Even it does, maybe do that in a future PR).

Could you add the new kwarg to the two respective docstrings?

I don't believe it makes sense, or at the very least would not be possible without more extensive changes; I would have to think about how to accomplish this, we don't get it for "free" from the state in this case.

Do we want the kwarg in the docstrings? WeakCompositions (which is the only existing EnumerativeCombinatorics iterator that already used this) doesn't have one, I thought maybe this was by design.

[lgoettgens]

So if I understand correctly, the "inplace" kwarg only exists for the case of combinations(::Int, ::Int), and not combinations(::Vector, ::Int), right? Does it make sense to also allow it in the former case? (Even it does, maybe do that in a future PR).
Could you add the new kwarg to the two respective docstrings?

I don't believe it makes sense, or at the very least would not be possible without more extensive changes; I would have to think about how to accomplish this, we don't get it for "free" from the state in this case.

Do we want the kwarg in the docstrings? WeakCompositions (which is the only existing EnumerativeCombinatorics iterator that already used this) doesn't have one, I thought maybe this was by design.

Two good points, then better leave it like it is (at least for now).

But could you please add a test that makes use of the new kwarg?

[mjrodgers]

As long as all the tests still pass after my most recent change, I think this is ready to merge; I will open an issue to bring up the discussion of Int vs BigInt for the length methods applied to combinatorial structures, and a separate pull request to add details about multicombinations / number_of_multicombinations to the Oscar documentation (since that requires some changes that are somewhat orthogonal to the rest of this pull request).