Improve Attribute Resolution Logic for Non-Three.js Properties

[acdzh]

I noticed that there was a previous commit which left a TODO regarding this issue:
645410e#diff-861bbdd4c9edaf2af00e9759390a2c40190a4a5c9342272be56751a6533ef323R266

Currently, when using attributes in the aaa-bbb format on a node, the resolve function parses them as root['aaa']['bbb']. This works well for nested properties on Three.js objects. However, in certain scenarios, if the attribute provided by the user is not a nested property on a Three.js object, it can lead to exceptions.

For example, some libraries that provide React inspector functionality (such as react-dev-inspector) add attributes like data-inspector-line or data-inspector-relative-path to all nodes at compile time to indicate which source file the element originates from. Although nodes within a Canvas are not actually rendered to the DOM, this can still cause conflicts at runtime.

Would a better approach be: for attributes in the aaa-bbb format, if aaa is indeed a property of root, we proceed with the original logic. If aaa is not a property of root, we simply preserve the original attribute name as is?

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 956355a:

Sandbox	Source
example	Configuration

[krispya]

Closed in favor of #3576