grt: do not update resources for pin access during incremental mode

[openroad-ci]

This PR has three main fixes:

1. Avoid calling addResourcesForPinAccess function for designs that don't have macros/PADs;
2. Avoid calling this same function during incremental iterations. This is important to avoid adding more resources than necessary in the incremental runs, which can lead to wrong congestion estimation.
3. Avoid iterating the pins of every net. Instead, only iterate the pins of nets connected to PADs or macros.

[gemini-code-assist]

Code Review

The pull request introduces optimizations to the addResourcesForPinAccess function by avoiding its execution for designs without macros or PADs, skipping it during incremental iterations, and filtering nets to only iterate over those connected to PADs or macros. While these changes improve efficiency and correctness in incremental mode, there are a few issues regarding the handling of BTerms (boundary pins) which are also PADs. Specifically, BTerms should trigger the has_macros_or_pads_ flag and the net-level isConnectedToPadOrMacro flag to ensure they are correctly processed when necessary. Additionally, the new has_macros_or_pads_ member should be reset in the clear() method to maintain consistency across multiple tool runs.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[eder-matheus]

PR with metric updates: The-OpenROAD-Project/OpenROAD-flow-scripts#3914

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"