Draft: allow multiple tasks consuming each a specified number of command-line arguments

[fero14041]

Hi, Paver mailing-list!

Starting using Paver, I was wondering why ``@consume_args`` does not allow
consuming a specified number of command-line arguments, instead of consuming
*all*. I can imagine several use-cases where user would like to call
e.g. three tasks, and pass `a` arguments to the first, none to the second,
`b` to the third, and all remaining to the last.
Ex., with ``version``, ``generate_setup``, ``commit`` and ``tag`` as tasks:

    paver  version 0.1  generate_setup  commit "Preparation for version 0.1"  tag

So I tested a first (and potentially very naive) implementation:
https://github.com/paver/paver/pull/68
I copy below message from this pull-request.

This implementation is based on a new decorator, :func:`tasks.consume_nargs`,
similar to :func:`tasks.consume_args` (and superseeds it), but accepting
an argument: the number of command-line arguments the decorated function
will consume. If no argument is passed to `consume_nargs` decorator,
all command-line arguments will be consumed;
also :func:`tasks.consume_args` is now an alias for ``tasks.consume_nargs()``.

This should allow calls of multiple tasks with arguments
(and only the last consuming all not yet consumed args).
For example in a pavement.py::

    @task
    @consume_nargs(2)
    def test1(options):
        print options  # should be ["1", "2"]

    @task
    @consume_nargs()
    def test2(options):
        print options  # should be ["3", "4", "5"]

and call on command line::

    paver  test1  1 2  test2  3 4 5

Under the wood, :data:`paver.tasks.Task.consume_args`'s type is changed,
from a boolean to an integer specifying the number of arguments to consume.
By default, it is set to ``0``. For a decorated task with ``@consume_nargs``,
if this number is not specified, the attribute is set to ``float('inf')``.

What are your opinion(s) about it?

Regards,

-- fero14041