applied to many fixed sources, corresponding to previous two commits

gratuitous strict mode incompatibility. Too many to continue fixing
manually this way. Don't know what to do about that.

Fixed convert.py to convert a "use strict" into an @strict_only

bogus semicolon. Except for the bogud semicolon, nothing should have
changed the meaning of the programs.

form, they now convert correctly to tests that pass our
tools/test262.py test runner. The issue for all three was non-ascii content.

These are the three files that "diff" identified as "binary" files with differences from the Sputnik original. Restoring to their original Sputnik state.

etc, because the substitution logic in test262.py operates on the
source after prepending framework.js.

The plan is to replace sputnikLib.js with framework.js. Also, the
substitution logic in test262.py should probably be fixed to apply the
substitution before prepending.

testRunner, test262.py, that can run all the converted tests.

assertTrue became assertTruthy. Canonical form of doc-comment attribute value source no longer have a leading colon and trailing semicolon. Any existing such are stripped during conversion.

preparation for deriving a test262 command-line runner.

style to append runTestCase(funcName); rather than
assertTrue(funcName.call(this)), giving the testing framework more
control.

morning. The rewrite of "function testcase()..." now puts the
assertTrue at the bottom. Preconditions, names, and ids are
removed. And the path in the file is ignored, and is instead set
accurately according to where the file is found.

Much rougher: A first attempt at building the testcases for the website based on the new canonical test262 style testcase.

- a lot of JS harness code written in strings have been moved out to actual physical files
  such as ed.js (syntax error detection for globally scoped tests) and gs.js (global scope test
  case validator).  This change makes it far easier to maintain the test harness code
- reorganized helper.js providing a clear indication which methods are used by external objects,
  which are implementation details, and which are unequivocally test262-specific.  I've also added,
  openErrorWindow, which will be used to open a descriptive error message window for each test case
  failure reported on the 'Run' tab
- improved the error message for syntax errors occurring when a test case fails to load
- sta.js no longer tries to pickle all helper functions it contains!  Instead, we load the file
  directly from sth.js.  The performance of fnGlobalObject has been improved.  Finally, the ES5Harness
  object has been moved from sth.js (in a string) to here
- sth.js now has a browser implementer hook, controller.implementerHook, which allows browser implementers
  to handle test case failures in their own way (e.g., log to the filesystem).  The 'run' function was
  basically re-written

Added 37 new test cases from the "IE Test Center" Build release.  There were 14 modifications to
existing test cases as well.  Refactored SputnikGlobalScope.js such that test case paths are now used
as indices into the GlobalScopeTests array.

TestCasePackager.py had the concept of templated test harnesses introduced - see templates\runner.test262.html.
Also added support for one HTML test harness per ES5 chapter.  Last but not least, TestCasePackagerConfig.py
now has a 'source control' abstraction class which abstracts away source control adds|edits when dynamically
generating *.json and *.html test chapters.

for the Build 2011 conference.

15.4.4.15-3-14, 15.4.4.15-3-29, and 15.4.4.15-3-8 were disabled with no reason or bug given. These actually look OK,
and pass on all browsers...

	if (!strict_mode) { throw new SyntaxError('unspecified case'); }

This doesn't work for a few reasons:
1.  'strict_mode' is undefined in the test case exeuction context. That is, the test framework
    does not force the test case into strict mode
2.  The test case code looks like:
	"use strict";
	if (!strict_mode) ...
        ...
    Note that 'strict_mode' is not set before being accessed

Really the metadata for these test cases should have a "@strict" property added to instruct the test
framework *not* to run the test if an implementation doesn't support strict mode.