Update mlton compile options

[MatthewFluet]

Closes #437

MLton's polyvariance optimization duplicates small higher-order
functions.

One (unresolved, though usually not significant) issue is that
polyvariance can duplicate code local to a function, even if it
doesn't depend on the higher-orderness (see
http://www.mlton.org/pipermail/mlton-devel/2002-January/021211.html).
This seems consistent with the discussion at MLton/mlton#196.

[MatthewFluet]

There may also be a beneficial impact on the runtime of the resulting bin/redprl. I looked at https://travis-ci.org/RedPRL/sml-redprl/jobs/305363531 (the last TravisCI build of master) and compute the testing runtime as: 541.45 (Travis reported time for ./script/test-${COMPILER}.sh) − 416.15 (MLton reported compile mutator time) − 121.60 (MLton reported compile GC time) = 3.7s (testing time) and at https://travis-ci.org/RedPRL/sml-redprl/jobs/305363531 (the TravisCI build of this PR) and compute the testing runtime as: 35.38 − 27.64 − 5.88 = 1.86s.

[jonsterling]

@MatthewFluet Wow, cool! Thank you!!

[MatthewFluet]

Though, I'm now even more curious to figure out idiom is behaving so badly with polyvariance. Looking again at the TravisCI logs, I see that with polyvariance, 177 assembly files are generated while without polyvariance, only 17 assembly files are generated.

[jonsterling]

I'm really curious about it too...