Foundation Classes - Fix bucket array leak in Poly_MergeNodesTool

[mbait]

Summary

Poly_MergeNodesTool::MergedNodesMap derives from NCollection_BaseMap but defines no destructor. The base destructor is = default and relies on each subclass calling Destroy() to free the hash bucket arrays (this is what NCollection_DataMap et al. do via Clear(true)), so the bucket array allocated by NCollection_BaseMap::BeginResize() leaks on every Poly_MergeNodesTool instance — i.e. on every STL/OBJ/mesh read that merges nodes (RWStl_Reader, RWObj).

The leaked size scales with mesh size: 2 * nbFacets buckets when the facet count is known, or the 995329-bucket default (~8 MB per import on 64-bit) when it is not. The map nodes live in the handle-held NCollection_IncAllocator and are released correctly — only the raw bucket array leaks.

LeakSanitizer evidence

Reported downstream against prebuilt V8_0_0_p1 Release libs (farfield-ru/libocct-build#1); resolved stack (LSan with fast_unwind_on_malloc=0):

#1 Standard::Allocate(unsigned long)                       libTKernel
#2 NCollection_BaseMap::BeginResize(...)                   libTKernel
#3 Poly_MergeNodesTool::MergedNodesMap::Bind(...)          libTKMath
#4 Poly_MergeNodesTool::PushLastElement(int)               libTKMath
#5 RWStl_Reader::ReadAscii(...)                            libTKDESTL
#6 RWStl_Reader::Read(...)                                 libTKDESTL
#7 RWStl::ReadFile(...)                                    libTKDESTL
#8 StlAPI_Reader::Read(TopoDS_Shape&, char const*)         libTKDESTL

A one-triangle ASCII STL leaks 7,962,640 bytes per StlAPI_Reader::Read() call (the unknown-size default path).

Fix

Add the missing destructor calling Destroy(DataMapNode::delNode, true), matching the idiom used by the other NCollection map classes.

Verification

ASan/LSan-instrumented host performing StlAPI_Reader::Read() + BRepBndLib::Add():

• before: Direct leak of 7962640 byte(s) in 1 object(s) with the stack above, nonzero exit;
• after: no LSan report, exit 0.

Also rebuilt Release/Debug/RelWithDebInfo shared-library configurations on Linux (GCC 13) and Windows (MSVC, Ninja) with this change applied on top of V8_0_0_p1 — no build or functional regressions observed in STEP/IGES/STL/OBJ import paths.

[dpasukhi]

Dear @mbait thank you for your investigation and detection of leak!

Thank you for your patch. To proceed with integration, please complete signing CLA process:
The links: Contribution Guide
Or https://dev.opencascade.org/get_involved

In case if you already have signed CLA, please share ID that OCCT team shared with your by email after accepting of CLA.

[mbait]

I've submitted the signed CLA, waiting for approval.