Make sure that domReady(), when used as a function rather than a plugin, executes registered callbacks sequentially.    This is how ready() is supposed to work, so it makes sense for domReady() to follow suit.

Fixes #16389, refs #16386 on 1.8 branch.

This is a combination of 3 commits:

-----
Make sure that domReady(), when used as a function rather than a plugin, executes registered callbacks sequentially.    This is how ready() is supposed to work, so it makes sense for domReady() to follow suit.

Plus, it's needed to make ready() work as advertised, since ready() calls domReady() internally.  Note that it's still dodgy that there are two queues, one in dojo/ready and one in dojo/domReady.   However, since dojo/ready is essentially deprecated, that's probably not worth fixing.

This fix is mainly a recursive guard, i.e. if f1() calls domReady(f2), f2() will be delayed until f1() completes.   However, it also addresses a concurrency issue:

In Editor_mouse.html on chrome I noticed that DOH started running the tests while test_Editor.s dojo.ready() callback was still executing.   It was mainly because the ready(999, ...) call from DOH occurred while the test_Editor.html dojo.ready() callback was running.   Normally browsers don't run multiple threads but I guess this is an exception since DOH and test_Editor.html are in different frames.

Also added a try/catch around each domReady() callback so that a failure in one callback won't affect other code, and won't get the guard variable stuck.

Fixes #16389, refs #16386 !strict.

git-svn-id: http://svn.dojotoolkit.org/src/dojo/trunk@30057 560b804f-0ae3-0310-86f3-f6aa0a117693
(cherry picked from commit e41487e670984085567db9a30a0ef6150b8f6a12)

-----

Second try to get dojo/ready and dojo/domReady! to play nice together.   dojo/ready still needs to yield to any tasks registered via domReady(), but callbacks in the dojo/ready queue cannot be removed until they are ready to be run.   Fixes #16389 !strict.   Needed to add some hooks into the dojo/domReady code so that dojo/ready can yield to tasks in that queue, but they can be removed for 2.0.

git-svn-id: http://svn.dojotoolkit.org/src/dojo/trunk@30282 560b804f-0ae3-0310-86f3-f6aa0a117693

-----

Get dojo/ready working on a non-browser environment again, so the builder works.   I'm unclear why dojo/ready is getting called at all in that case though.  Refs #16389, fixes #16557 !strict

git-svn-id: http://svn.dojotoolkit.org/src/dojo/trunk@30322 560b804f-0ae3-0310-86f3-f6aa0a117693
(cherry picked from commit 328a0a21c74a73e9cb1ade61ba025ccd6aa9f758)