Change Fasta testing docs to use 32-bit when possible.

pkg/front_end/lib/src/fasta/TESTING.md

 <!--
 Copyright (c) 2017, the Dart project authors.  Please see the AUTHORS file
 for details. All rights reserved. Use of this source code is governed by a
 BSD-style license that can be found in the LICENSE file.
 -->
 # How to test Fasta
 
 When changing Fasta, your changes can affect dart2js or the VM, so you may need
 to test them.
 
+Most of the tests below use a 32-bit build because the test runs significantly faster.

[ahe, 2017/03/15 14:58:51]

Should we include the command line for building? I use:

./tools/build.py --mode release --arch x64,ia32 runtime_kernel
dart_precompiled_runtime

We need to build remember to build before running -cdartk tests, as we otherwise
will be running the previously built version of Fasta.

[Paul Berry, 2017/03/15 17:24:09]

I actually think we're ok with what we've got.  For the test commands on lines
20, 29, and 32, it's not necessary to do a build.  For the test command on line
43, a build is necessary, but the command on line 43 takes care of it (note that
it says `./tools/build.py ... && ...`).

If you want to propose a CL that spells this out in more detail I'm open to it,
though.

[ahe, 2017/03/16 08:39:27]

Good point.

+
 <!-- TODO(ahe): Soon, also the analyzer. -->
 
 ## Test package:front_end and package:analyzer.
 
 The absolutely bare minimum of testing is the basic unit tests:
 
 ```
-./tools/test.py -mrelease 'pkg/front_end|*fasta*' --checked --time -pcolor --report --failure-summary
+./tools/test.py -mrelease 'pkg/front_end|*fasta*' --checked --time -pcolor --report --failure-summary -aia32
 ```
 
 ## Testing dart2js
 
 If you're making changes to dart2js, it most likely involves the scanner or parser (at least for now). In that case, you should run dart2js' unit tests (the test suite called dart2js) as well as language and co19.
 
 ```
 # Unit tests for dart2js
-./tools/test.py --dart2js-batch --time -pcolor --report --failure-summary -ax64 -mrelease --checked dart2js
+./tools/test.py --dart2js-batch --time -pcolor --report --failure-summary -aia32 -mrelease --checked dart2js
 
 # Language and co19, dart2js.
-./tools/test.py --dart2js-batch --time -pcolor --report --failure-summary -ax64 -mrelease -cdart2js -rd8 language co19
+./tools/test.py --dart2js-batch --time -pcolor --report --failure-summary -aia32 -mrelease -cdart2js -rd8 language co19
 ```
 
 ## Testing the Dart VM
 
 If you're making changes that affect Kernel output, for example, BodyBuilder.dart, you probably also need to test on the VM:
 
+Note that this test requires a 64-bit build because app-jit snapshot does not work for ia32.
+
 ```
 # Language, co19, kernel, for VM using Fasta.
 ./tools/build.py -mrelease runtime_kernel && ./tools/test.py -mrelease -cdartk co19 language kernel --time -pcolor --report --failure-summary -j16
 ```
 
 
 Notice that the option is -cdartk, but it is actually Fasta. Not dartk.
 
 If you're running on a Mac, it's important that you use the -j option with test.py. It defaults to the number of cores on your machine (including hyper-threads), and for Linux that works fine. But Macs don't seem to be able to run as many processes in parallel. On a Mac Pro with 24 threads, using -j16 seems optimal.