After duplicating entries, make the callers use the new entries

Another step in exercising the multi-entry pipeline, this pass has been
modified so that callers of the duplicated functions will exercise the
new entry points.

The next step is to have callers pick at random from a list of
replacement entry points, so that both entry points will be exercised
(by different callers).
Don't rename the start block of the entry being duplicated

The default SSA pipeline has been modified to duplicate function entries
before and after all of the other SSA passes.  This way, we see how the
other passes behave with multiple entry points while making sure that
other passes down the pipeline will have plenty of functions with
multiple entry points to work with.

When duplicateEntries ran before and after the shrinker, the shrinker
would notice that for nullary entry points (notably, main), the extra
blocks didn't need to be added to forward the arguments so they were
reduced to one block that all of the duplicated function entries would
use.

The original implementation of duplicateEntries replaced the start block
of the function it was duplicating.  Because of this, when duplicating
the entries again after the shrinker ran, the start block for the
duplicate entry point had already been removed from the function (and we
had no idea what it had been re-named to).  As a result, the second
pair of duplicated entry points would jump to their entry block, then
immediately jump to an undefined label.

This was fixed by not re-naming the original start block --- only
changing its arguments.  This way, we can safely duplicate entries, even
if they all jump to the same block.
Port remaining SSA and SSA2 optimization passes to multi-entry

This pull request converts many of the simple SSA and SSA2 optimization
passes to multi-entry. Many of the conversions were trivial (the entries
were unused by the analysis and were simply copied unchanged to the
transformed function). The other conversions had no significant
difficulties with multi-entry.

In addition, there are a few additional changes:

1f6e6a7 Change the type of main field in {SsaTree,SsaTree2}.Program.T to
        {func: Func.t, entry: Entry.t} (as discussed in c536cac).
e1ce00d Move DuplicateEntries pass to front of SSA simplify pipeline, so
        subsequent passes must handle truly multiple entry functions.
1391278 Revise DuplicateEntries pass to simplify transformation and to
        use new entries.

I've run through the regression suite with these commits, and see the
following failures:

 * `echo`: Failure due to missing `MLton.Socket` structure;
    `multi-entry-funcs` branched between the time that I removed the
    deprecated `MLton.Socket` structure and removed the regression test
    that used it.

 * `exn-history`, `exn-history2`: Failure with `Backend.genStatement:
   strange statement: Enter <main>`, due to `multi-entry-funcs` not
   supporting profiling (which is used by exception history).

 * `finalize`, `finalize.2`, `finalize.3`, `finalize.4`, `finalize.5`,
   `finalize.6`, `mutex`, `prodcons`, `signals`, `signals2`, `signals3`,
   `signals4`, `suspend`, `thread2`, `timeout`, `world5`: Failure with
   `Rssa.checkScopes: duplicate definition of L_0`, most likely due to
   some error inserting limit checks into multi-(green)threaded
   programs.

These are all benign failures, at least for what we are focusing on with
the project.  It would be good to fix the multi-(green)threaded
programs, but I don't believe that is on the critical path.  It would
also be good to fix profiling, but we've explicitly left that to future
work at this time.

Quite surprisingly, it seems that the native codegen is working fine
with multi-func chunks.