Add support for sorted parsing

The rationale behind this proposal is a bug that resulted from the use of the parse function in Aseprite. It so happened that the position of arguments is sensitive in some instances. For example, in cases where values without any associated options (e.g file names) come before some options, Aseprite opens the file(s), parse and process the opened file(s) before moving on to processing the other arguments. In some of these cases, the options provided via the CLI may be what is supposed to drive how the file is opened, parsed and processed. However, if the file is eagerly processed before the arguments, it results in some hard-to-debug bugs. This PR allows the user have two options:

get access to the CLI values/options as-is
move the option-less values to the end of "queue"

This second option delays the eagerness to open/process option-less values until all driving forces are properly taken care of. If, from Aseprite, we could have direct mutating access to the underlying values and options parsed, there would not have been a need for this PR but (rightly so) the interface exposed is immutable -- thus why I think this PR may be needed.

PS: I am not so sure the name of this function (sortedParse) is the right name for it, but as at the time of making this amendment, this is the only name I could think of.

ADDENDUM: According to this comment, this PR may not be necessary as the Aseprite opened issue isn't really a bug but a feature.

aseprite / laf

Add support for sorted parsing #42