fix `scoop update` to allow safe scoop CMD shim updates
fix `scoop update` to allow safe scoop CMD shim updates

* fixes #481

.# Discussion

When `scoop update` is executed from the CMD line, the scoop CMD shim (`scoop.cmd`) is
used to initiate execution, calling the scoop application. The scoop application then
performs the update (which regenerates the CMD shim) and terminates. Upon exit from the
scoop application, control flow returns to the newly regenerated CMD shim and execution
continues to a final termination.

This process is most often completely benign because the CMD shim is usually regenerated
with an identical copy. So, when control flow returns to the CMD shim and execution
resumes, it continues along the known, expected path. However, if the regenerated CMD
shim is *not* identical, control flow returns to an alternate location within the script,
leading to a high likelihood of an unplanned and error-prone execution path on the way to
final termination.

Control flow is well-defined when CMD shells out to another executable (.COM or .EXE) or
calls another BAT/CMD script. The CMD shell reads and parses the hand-off statement,
saving a pointer to the character location just past the end of the statement. Then the
CMD shell executes the hand-off statement, transferring flow of control. When the called
executable/script exits, control flow returns to the original script, reading and
executing from the saved character location within the script file. Testing shows that if
the hand-off statement is enclosed within a parenthesis statement block, that block is
fully read, parsed, and kept in memory for execution upon return of control flow; flow of
control is returned to the character location at the end of that block. Testing also
shows that the location "end of statement" includes any single CRLF trailing the
statement/block, if present.

Given this process by the CMD shell, it is extremely difficult to plan a well defined
execution path after modifications are done to an executing script, since it is dependent
on the modification and the original source file execution path. Creating a generic,
well-functioning update method is essentially impossible unless we simplify the issue by
disallowing return of execution to any newly modified code path. This can be accomplished
in one of two ways: 1. handing off flow of control with no return by executing another
BAT/CMD script without using `call` (aka, proxy execution); or 2. constructing a
parenthesis-block which contains the hand-off and ends the script within the block itself
(eg, via `goto :EOF`; this is the only alternative possible for hand-off to executables
which are not BAT/CMD scripts). Going forward, using either of these two methods will
allow any in-use modification of the `scoop` BAT/CMD shim, without limitation.

For past versions of `scoop`, we don't have either of the two simplifications in place.
But we can use the fact that past shims were all constructed to hand-off to `scoop.ps1`
using the last command in the script to give us a known control flow return location, eg,
the character position one past the original CMD shim file size.

Using this known return location, a script can be built which allows the usual return and
completion of the current process without error and also executes subsequent runs
correctly. To do this, code for future execution paths is embedded within the space
before the point at which execution returns, filler is added up to the return location,
and then finalization code is added so that the current process finishes correctly.

rivy/scoop