Made the stack analyze binary search require several consecutive fill words, so unwritten holes in a used stack no longer cause the highest stack pointer to be under-reported

[fdesbiens]

Fixes #425

_tx_thread_stack_analyze() binary-searches the stack for the boundary between the untouched fill pattern and the region the thread has actually used. The probe accepted a location as unused as soon as a single word still held TX_STACK_FILL. A word inside an otherwise used region that simply was never written — the padding of a partially initialized local array, for example — therefore sent the search away from the real boundary, and tx_thread_stack_highest_ptr ended up reporting far less usage than the thread had really consumed. As the reporter observed, that also keeps the stack guard from firing when it should.

The probe now walks down from the candidate location and requires TX_THREAD_STACK_ANALYZE_FILL_WORDS consecutive fill words before it treats the location as unused. It stops early at the lowest location already known to hold the fill pattern, so locations near the bottom of the stack behave correctly. The new macro defaults to eight words and can be overridden in tx_port.h; setting it to one restores the previous behavior exactly.

This is the approach @billlamiework proposed in the issue thread. It remains a heuristic — a hole at least as long as the configured run can still mislead the search — but it removes the common single-word and short-hole cases at a cost of a handful of extra reads per binary search iteration.

The same change is applied to the SMP copy of the file, which was byte-identical to the non-SMP one.

Validation: an offline model of both algorithms confirms that a six-word hole placed on a probe location makes the current code report 88 words less usage than the thread actually used, while the new code lands on the true boundary; results are identical for stacks with no holes. The regression suites pass unchanged: 98/98 for test/tx and 114/114 for test/smp.