Choose TDML implementation to run TDML tests

New description

Add TDML implementation option to Daffodil's CLI test subcommand and extend Runner API with TDMLImplementation parameter (defined by dafext.xsd) to allow running the same TDML file with any specified TDMLImplementation without having to change the TDML file.  Run runtime2 TDML and Scala tests with TDMLImplementation specified through Runner API, not tunable.

Also fix some inconsistencies with fill bits overlooked by a previous pull request which extended runtime2 to read and write N-bit numbers.

Original description (outdated)

It would be very nice if we could run the same TDML file with either runtime1 or runtime2 without changing the TDML file.  Right now the only way to run a TDML file or test with runtime2 is to define a "runtime2" config (which could be a file or an embedded config) and use it in either defaultConfig="runtime2" on the TDML file or config="runtime2" on the TDML test.  Is there any reason why the daffodil test subcommand can't accept the same `-c, --config <file>` and `-Ttunable=value` options as most of the other subcommands, build a tunables object, and pass it to the Runner?  Most of the other subcommands pass a tunables object from the CLI to the rest of Daffodil, but I read a comment on DFDLTestSuite that says

 * Keep this independent of Daffodil, so that it can be used to run tests against other DFDL implementations as well.
 * E.g., it should only need an API specified as a collection of Scala traits, and some simple way to inject
 * dependency on one factory to create processors.

Can the CLI still pass a tunables object explicitly to DFDLTestSuite anyway, or pass it implicitly somehow?