In commit e90d54d of PR git-lfs#2329 the
"git/githistory/log" package was added, including the PercentageTask
structure and associated methods.  Then in commit
122b765 of PR git-lfs#2610 the Entry()
method was added to provide support for verbose logging in the
"git lfs migrate impot" command.  However, the name of the
receiver argument for the Entry() method differs from that of
the other methods for the PercentageTask structure, so we update
it to match now, as well as fixing a typo which remains from the
original commit in PR git-lfs#2329.

Note that the "git/githistory/log" package was later renamed to the
"tasklog" package in commits b9ab79e
and 45c580e of PR git-lfs#2747.

In commit 3129b9a of PR git-lfs#2537 the
"githistory" package was updated so the WithLogger global option
variable now required a *log.Logger argument instead of calling
log.NewLogger().  This was done so the "git lfs migrate" commands
could pass in a previously initialized logger to which the commands
had already written log messages; that change was introduced in
PR git-lfs#2538.

In the same commit of PR git-lfs#2537, a WithLoggerTo global option function
was added to preserve the existing behaviour.  However, this option
has never been utilized, and so to reduce unnecessary complexity
we just remove it now.

Note that the use of functional options in the Git LFS project
stems from PR git-lfs#2295 and is inspired by the design proposed in several
articles from 2014; see, for reference:

https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html

The SimpleTask structure of the "tasklog" package, which was introduced
in commit 7a760b6 of PR git-lfs#2756, is used
at several points in the implementation of the "git lfs fetch" and
"git lfs prune" commands, and in each case is constructed with a
call to the NewSimpleTask() function, and then passed to a Logger
structure's Enqueue() method.

However, in commit 0cad488 of PR git-lfs#2767,
a Logger.Simple() method was added to both create a new SimpleTask
structure and pass it to a Logger structure's Enqueue() method.  This
Logger.Simple() method was added to be consistent with other existing
similar methods such as Logger.List() and Logger.Percentage().

These other methods are used consistently throughout our code
to create and enqueue tasks, so we now update the locations where
we call NewSimpleTask() to use the Logger.Simple() method instead.

This also provides an opportunity to tidy some of the surrounding
code and whitespace.

In commit f100293 of PR git-lfs#2732 a local
maxInt() function was added to the "git/githistory/log" package in order
to avoid a circular dependancy on the "tools" package, which provides
a common MaxInt() implementation.  See, for reference, the discussion
in this PR comment:

git-lfs@f100293#r151551639

The "git/githistory/log" package was subsequently renamed to
the "tasklog" package in commits b9ab79e
and 45c580e of PR git-lfs#2747.

At present, though, there is no cyclic dependency which prevents
the use of the standard tools.MaxInt() function in the "tasklog"
package, so we revert to its use now.

The *Logger.consume() method in the "tasklog" package was first
introduced in commit e90d54d of
PR git-lfs#2329, and since that time has included logic to manage an
internal "pending" list of tasks; however, that logic is never
exercised because tasks are only appended to the "pending" array
when the "next" variable is non-nil, but that variable is
initialized as nil and can only be set to another value if the
"pending" array is non-empty.

As a result, we can remove both variables and the related logic
and simplify the consume() method as a result.

In commit e90d54d of PR git-lfs#2329 the
"git/githistory/log" package was added, including the PercentageTask
structure and associated methods, but unlike the WaitingTask which
was added at the same time, no Complete() method was defined for
the PercentageTask structure.

(Note that the "git/githistory/log" package was later renamed to the
"tasklog" package in commits b9ab79e
and 45c580e of PR git-lfs#2747.)

Other task types such as the ListTask and SimpleTask structures
(introduced in commit 31ffeb9 of
PR git-lfs#2335 and commit 7a760b6 of PR git-lfs#2756,
respectively) provide a Complete() method, and the Meter task type
of the "tq" package, which implemented the Task interface in commit
7c0f9e2 of PR git-lfs#2732, provides an
equivalent Finish() method.  These methods allow the caller to
explicitly close the channel returned by the Updates() method,
on which the anonymous goroutine started by the Logger.consume() method
for the task is waiting, in a "range" loop on the channel in the
Logger.logTask() method.

One key use of the PercentageTask structure is in the methods of
the Rewriter structure from the "git/githistory" package.  It is
initialized with the number of commits to be rewritten during
a "git lfs migrate" command's traversal of a Git repository's history.
As each commit is rewritten, the Count() method is called to
increment the percentage completed value.  When every commit has
been rewritten, the count reaches the expected total, and the
Count() method closes the channel, thus allowing the task receiving
updates to finish and exit its goroutine.

Under exceptional circumstances, though, the Rewrite() method of
the Rewriter structure may never finish iterating through all
the expected commits, and return in error or via a panic call.
When this happens, the goroutine waiting on the PercentageTask's
updates channel can never exit, leading to a hung process which
never fully exits.

In order to allow the Rewriter's Rewrite() method to define a
deferred function which will always be called when it returns,
under any circumstances, we add a Complete() method for the
PercentageTask structure which sets the number of completed elements
to the expected total in an atomic swap, and then closes the
updates channel if the number of completed elements was previously
less than the expected total.

We also add a test to validate this new method's behaviour, and
update the existing TestPercentageTaskCallsDoneWhenComplete()
function to also confirm that calling the new Complete() method
after the number of completed elements has reached the expected
total does not cause a second attempt to close the updates channel.

In a prior commit in this PR, we added a Complete() method for
the PercentageTask structure which sets the number of completed
elements of the task to the task's expected total in an atomic swap,
and then closes the task's updates channel if the number of completed
elements was less than the expected total.

As noted in that same commit, the PercentageTask structure is used
in the methods of the Rewriter structure from the "git/githistory"
package.  It is initialized with the number of commits to be rewritten
during a "git lfs migrate" command's traversal of a Git repository's
history.  As each commit is rewritten, the Count() method is called to
increment the percentage completed value.  When every commit has been
rewritten, the count reaches the expected total, and the Count() method
closes the channel, thus allowing the task receiving updates to finish
and exit its goroutine.

Under exceptional circumstances, though, the Rewrite() method of
the Rewriter structure may never finish iterating through all
the expected commits, and return in error or via a panic call.
When this happens, the anonymous goroutine started by the consume()
method of the Logger structure in "tasklog" package that is waiting
on the PercentageTask's updates channel can never exit, leading to
a hung process which never fully exits.

We can resolve this problem now by defining a deferred call to the
PercentageTask's new Complete() method after we create the task
structure in the Rewrite() method of the Rewriter structure.
As a result, even if the Rewrite() method suffers a panic() or
other error condition causing an early return, the PercentageTask's
updates channel is closed and the waiting goroutine will complete
and exit normally.

This usage corresponds to the resource management approach used
elsewhere, such as in the scanAll() and pointersToFetchForRefs()
functions of the "git lfs fetch" command, where SimpleTask objects
are created and a deferred call to their Complete() method is
immediately established.  This technique is also used in the
UpdateRefs() method of the refUpdater structure in the "git/githistory"
package, where a ListTask is created and a matching deferred call
to its Complete() method is then defined.

In a prior commit in this PR, we added a Complete() method for
the PercentageTask structure which sets the number of completed
elements of the task to the task's expected total in an atomic swap,
and then closes the task's updates channel if the number of completed
elements was less than the expected total.

As noted in that same commit, this allows us to establish a deferred
call to the Complete() method after creating a PercentageTask structure,
akin to how we handle other "tasklog" package task structures such as
ListTask and WaiterTask.  Use of this idiom ensures that even if the
calling function returns due to an unexpected error or panic condition,
the anonymous goroutine started by the consume() method of the Logger
structure that is waiting on the task's updates channel will exit
cleanly, preventing a hung process.

We therefore now update the other use of the PercentageTask structure,
in the "git lfs prune" command's pruneDeleteFiles() function, to
follow the same approach as we have already implemented for the
Rewrite() method of the Rewriter structure in the "git/githistory"
package.

In the implementation of several commands we create structures with
the Task interface from the "tasklog" package, and enqueue them to be
reported by an anonymous goroutine created by the Logger structure's
consume() method for each task.  These goroutines only exit when the
channel returned by the the Task's Updates() method is closed.

In order to ensure that we always close the channel associated with
each task, we refactor the creation and use of these tasks into small
utility functions.  We can then establish a deferred call to the
tasks' Complete() methods immediately after creating the tasks.
As these deferred calls will always be executed when returning from
the new utility functions, even under exceptional conditions, the
waiting goroutines will never fail to exit and thus cause the entire
program to hang.

This usage corresponds to the resource management approach used
elsewhere, such as in the scanAll() and pointersToFetchForRefs()
functions of the "git lfs fetch" command, where SimpleTask objects
are created and a deferred call to their Complete() method is
immediately established.  This technique is also used in the
UpdateRefs() method of the refUpdater structure in the "git/githistory"
package, where a ListTask is created and a matching deferred call
to its Complete() method is then defined, and in previous commits
in this PR we updated the locations in our code where we create
PercentageTask structures to follow the same pattern too.