Adds an API for changing the default stack size limit.

Deprecated in favor of <http://codereview.chromium.org/242014>;.

Adds an API for changing the default stack size limit.

The current 512K/1M default, kLimitSize, isn't appropriate for OS X. OS X has a 512K default thread stack size.

[dominic.cooney_gmail.com, 2009-09-18 09:05:12]

Here's a proposed minimal patch. It turns out to be convenient for workers,
which can be reentrant, to set stack limits relative to the first call in to the
runtime.

An alternative would be set limits per-thread, and let the user vary them in
flight. Is there a design doc for threads and interrupts? I'm having a hard time
understanding when it is legal to call i::StackGuard::SetStackLimit, c.f. the
conditions that i::StackGuard::StackGuard checks on first creation. 

The included test fails on the ARM simulator because GENERATED_CODE_STACK_LIMIT
is pegged to the simulator's stack limit, and so the assertion that a 4K stack
holds less activations than a 512K stack fails. I could weaken the first_depth >
second_depth assertion. Thoughts?

[dominic.cooney_gmail.com, 2009-09-22 09:30:01]

OK, here's another take on this--making the ResourceConstraints::set_stack_limit
API actually work. Just apply the test patch and run it and you'll see the CHECK
I mentioned when the initial StackGuard is created after the stack limit is set.

The rest of the change adjusts that CHECK to allow initial stack limits.

[dominic.cooney_gmail.com, 2009-09-23 19:42:57]

Let me recap what's going on:

Runaway recursion in workers crash with C++ stack overflows on OS X because the
default stack limit is too large for OS X threads.

There's an API--ResourceConstraints::set_stack_limit/SetResourceConstraints that
looks like it is intended to let users set up a stack limit manually. This API
doesn't work--in debug mode, the initial StackGuard::StackGuard invocation
CHECKS that the limits are still uninitialized (kIllegalLimit). In release mode
StackGuard::StackGuard goes ahead and overwrites any configured limits.

If you just patch the updated test-api.cc and run the SetResourceConstraints
test in debug mode and release mode you'll see these two problems exhibit.

In theory, if the v8::internal::StackGuard::SetStackLimit method was accessible,
external callers could call this after the first StackGuard is established to
re-set the limit. But that API isn't accessible. SetResourceConstraints isn't
usable because it also checks that Heap is not initialized.

This changelist makes the SetResourceConstraints API work, but I argue this
isn't what we want: this doesn't provide any way to set a stack limit per thread
(and consequently it breaks Threading and Threading2 tests.)

What would you like to see here?