…e patches

Loading zone.js under Node's --frozen-intrinsics (or SES lockdown,
or any environment that has frozen the relevant built-ins) crashes
at import. Two load_patches are responsible.

The toString patch dies trying to overwrite
Function.prototype.toString:

  TypeError: Cannot assign to read only property 'toString' of
  object 'function () { [native code] }'

The console patch dies one step earlier, when it tries to stash
the original method under a symbol-named property:

  TypeError: Cannot add property __zone_symbol__dir, object is
  not extensible

Node started freezing the console object a while back (see
nodejs/node#46044), so this is expected behavior on the runtime
side, not a Node bug — zone.js just isn't checking before it
writes.

The fix in both places is to look before leaping. For toString,
we inspect the descriptors of Function.prototype.toString and
Object.prototype.toString and skip the patch if either one isn't
writable or configurable. It has to be all-or-nothing: applying
only one of the two would make Promise objects stringify
differently depending on which path runs, which is worse than
not patching at all.

For console, we first check Object.isExtensible(console), then
check each method's descriptor individually. Console methods are
independent of each other, so a single locked-down method just
gets skipped while the rest are patched normally.

When the patches bail, you lose some behavior:

- Patched functions show their wrapper source through
  Function.prototype.toString instead of looking like native
  code. Anything that grep's for "[native code]" to detect
  natives will see different output.

- console calls from inside a non-root zone stay in the calling
  zone instead of being hoisted to Zone.root. The output still
  appears; it's just in a different zone context. Most code
  won't notice, but zone-aware logging setups might.

Neither is great, but both beat crashing at require().

Worth being clear about scope: this isn't "zone.js now works
under --frozen-intrinsics." The whole library is built around
mutating intrinsics, which is exactly what the flag forbids, so
that's a contradiction we can't resolve. The goal here is just
that the library shouldn't crash on import. A couple of other
load_patches have similar issues (patchMethod especially) and
can be hardened the same way in follow-ups.