feat(): IfcStatementScanner

[ShaMan123]

Description

A draft for #293, WIP

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following:

• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Follow the Conventional Commits v1.0.0 standard for PR naming (e.g. feat(examples): add hello-world example).
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[agviegas]

We've reviewed the direction and we're on board: the scanner plus the id index is the right foundation for #293 and for migrating the splitter onto the parsing layer, so feel free to build on it. Two asks when you take it out of draft: rebase onto current main (the Utils barrel changed), and export the new modules from the package root rather than the Utils barrel, so they never reach the worker bundle (that was the root cause of #289). Looking forward to it!

[ShaMan123]

A question about the end goal that #289 surfaced.
Do we want to eventually drop web-ifc as a dep, replacing IfcApi.GetLine calls with this solution?

[ShaMan123]

Let me rephrase my question: considering that splitting was devised to workaround ifc parsing limitations (OOM), with this change will splitting be needed? Could/should we consider this as a different approach replacing the need to split ifc files?