Optimize deferred

[spawnia]

Resolves #1803

Follow up to #1790

[spawnia]

Summary

This PR optimizes memory usage for deferred execution while preserving the DataLoader pattern that was broken in #1790.

Problem

PR #1790 attempted to optimize memory but broke DataLoader batching - batch loads executed incrementally before all IDs were collected, causing null values with 600+ items.

Solution

Reduces memory usage by replacing closure-based queue storage with direct object/array storage:

1. Store executor on promise instance - $executor property instead of closure context
2. Queue promise objects directly - enqueue($this) instead of enqueue(function() {...})
3. Use arrays for waiting handlers - [$promise, $onFulfilled, $onRejected, $state, $result] instead of closures
4. Explicit cleanup - $task->executor = null and unset($task) enable GC during long queues

Tests Added

• testDataLoaderPatternWithManyDeferredObjects() - 600 items, verifies single batch load
• testNestedDataLoaderPattern() - 750 items, reproduces Getting null instead of a list of items for v15.27.0 #1803 scenario

Verification

• Tests pass with optimization
• Tests fail when Optimize Deferred memory usage with incremental queue processing #1790 changes are cherry-picked (confirms they catch the regression)
• DataLoader pattern preserved - all IDs collected before first batch executes

[spawnia]

@shadowhand @zimzat @joshbmarshall Can you give this a review?

[joshbmarshall]

I loaded it up on the system that was having problems with v15.27.0

It still has issues with v15.27.0 tag, but this is working for me at 1954f81

For my query, the memory usage is identical for this pull request as for master branch. But I think it's because I have nested resolvers:

event date > event > event dates

I think it's waiting for all the event dates to be queued before resolving, which is how I'd expect it to be. I don't think that can be managed!