FINERACT-2684: Decouple transient collaborators from the SavingsAccount entity

[alberto-art3ch]

Description

Removes runtime service collaborators that were stored as @Transient/transient fields on the SavingsAccount JPA entity and injected after hydration via setHelpers(...). This kept infrastructure/config dependencies out of the domain entity's state.

• Removed transient fields savingsAccountTransactionSummaryWrapper, savingsHelper, and configurationDomainService from SavingsAccount, along with the setHelpers(...) post-hydration injection method.
• SavingsAccountTransactionSummaryWrapper: converted from a Spring @component into a final utility class with a private constructor; all calculateTotal* methods are now static pure functions over the supplied transactions.
• SavingsHelper: reduced to a thin service exposing only the DB-backed interest-transaction lookups. The stateless interest posting-period math (determineInterestPostingPeriods, calculateInterestForAllPostingPeriods) was extracted into the new static SavingsInterestCalculationUtil.
• Explicit parameter passing replaces the injected state:
  • calculateInterestUsing(...) now receives SavingsHelper as an argument.
  • validateAccountBalanceConstraints(...) / isForceWithdrawalAllowed(...) now take the resolved forceWithdrawalEnabled flag and forceWithdrawalLimit value instead of reaching into ConfigurationDomainService.
  • SavingsAccountSummary.updateSummary(...) / updateSummaryWithPivotConfig(...) no longer take a wrapper argument and call the static methods directly.
• Callers updated across savings/deposit services, assemblers, and Spring configuration to stop calling setHelpers(...), resolve the config values up front, and pass collaborators as method parameters.

No functional/behavioral change — pure refactor to decouple transient elements from the persistent entity.

FINERACT-2684

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

Your assigned reviewer(s) will follow our guidelines for code reviews.