Inplace Iterator Naming Convention

In my opinion, it would be great to have a naming convention for inplace iterators. ### Why? The [Oscar Developer Style Guide](https://docs.oscar-system.org/stable/DeveloperDocumentation/styleguide/#Naming-conventions) makes no statement about this and the [Julia Style Guide](https://docs.julialang.org/en/v1/manual/style-guide/#bang-convention) is ambiguous. On the one hand, `!` should be appended to function names if and only if the function modifies its input. To be precise, an inplace iterator does not modify its input. On the other hand, however, it provides an iterator which turns `Base.iterate(...)` into a function which modifies its input, but which cannot be written with a `!` for semantic reasons. ### Possible Solutions There are several possible ways to declare a naming convention for inplace iterators. Here are some examples: 1. `my_iterator(args)` for standard usage and `my_iterator(args, inplace=true)` for inplace variant 2. `my_iterator(args)` for standard usage and `my_iterator(args, modify_value=true)` for inplace variant 3. `my_iterator(args)` for standard usage and `my_iterator!(args)` for inplace variant 4. `my_iterator(args)` for standard usage and `my_iterator_inplace(args)` for inplace variant 5. `my_iterator(args)` for standard usage and `my_iterator_modify_value(args)` for inplace variant ### Some Remarks on the Suggested Solutions - The version `my_iterator(args, inplace=true)` exists at some places already e.g. `combinations` in OSCAR (n.b. `subsets` in Hecke has recently been rewritten in the same way). @fingolfin noted that a change to a different convention might result in the need for maintaining two conventions at the same time. - @joschmitt mentioned that, whatever convention we choose, we should explain it in the documentation, preferably in one central place, so that we can simply link to it. - Calling it _inplace_ might, perhaps, be easier understandable than _modify_value_. However, _inplace_ is not quite true, as `my_iterator` does not modify `args` but might change the value of the iterator instead. In the same way, also `my_iterator!` is not quite correct. - @fingolfin demonstrated (see below) that the additional Boolean check involved in a version using a keyword argument is, in practical terms, completely negligible in terms of time. - As @simonbrandhorst pointed out, shortcuts (e.g. `my_iterator_mv` instead of `my_iterator_modify_value`) should be avoided. - Feel free to add other possible solutions, comments or remarks!