Add support for detecting args after double-dash

[zdenek-crha]

The crate provides support for detecting and ignoring double-dash ("--")
argument passed from command line, but it does not provide any
information about its presence or position to user.

For applications that may want to pass arguments after double-dash to
child process is such indication critical.

Add optional field args_end into Matches structure storing position of
first argument after double-dash (if there is any) and method to provide
user access to the data.

When checking for double-dash positin, it is important to make sure that
there actually are some arguments after it. Otherwise the position would
point to non-existent index in free list and would require additional
unnecessary checks on user side.

[zdenek-crha]

I've been thinking about the change bit more and there is an alternative approach to handling args_end_pos. Instead of storing and Option<usize>, we could store just usize and say that if there are no arguments after double-dash, then the pos points after the last element of free vector.

Together with slices, it could be used for easilly extracting both lists:

let args = matches.free[0 .. matches.args_end_pos()];
let rest  = matches.free[matches.args_end_pos()..];

Not sure which approach would be better as far as crate API goes - the current one might be easier to understand on glance, second one offers consistent access to both args and rest without conditionals and matching.

[KodrAus]

Thanks for working on this @zdenek-crha

I like the approach of always returning a usize that may just point to the end of the free list. I think the name args_end_pos is a little non-descriptive though. Since it's an index into free I think it should be prefixed with free. Maybe we could call it free_trailing_start to indicate the position of args in the free list that are trailing after a --? That way you'd write something like:

let for_child = matches.free.get(matches.free_trailing_start()..);

if for_child.len() > 0 {
    ..
}

What do you think?

[zdenek-crha]

Sorry for late response @KodrAus, I've been busy with vacation :-)

I have no issue with renaming the method to free_trailing_start(). It is bit long for my liking, but it also describes its return value better than the name I have used.

I'll work on the change asap and force-push new version (I tend to use force-push instead of adding 'fixme' commits, let me know if you you prefer different way to update PR).

[KodrAus]

Thanks @zdenek-crha. This looks good to me.