FINERACT-2708: Fix duplicate defined name 500 in bulk-import transaction templates

[oluexpert99]

- Downloading the savings, recurring-deposit or fixed-deposit transaction template
    failed with HTTP 500 (IllegalArgumentException: The workbook already contains this
    name: Account_<client>_<id>_) on tenants where one client holds more than one
    account. The template is unusable for the whole tenant; there is no API workaround.
  - setNames builds one Account_<client>_<id>_ defined name per client, collecting
    clients by walking the account lookup table and starting a new run whenever the
    client name changes. That run detection uses a case-sensitive String.equals, but the
    table it walks was just sorted with SavingsAccountData.ClientNameComparator, which
    compares the names case-INSENSITIVELY (both upper-cased). Two clients whose names
    differ only in case therefore compare equal to the sort and may be interleaved, which
    splits one client's accounts into two runs; the second run re-adds the same client
    and the per-client loop then asks POI to create a defined name that already exists.
  - Guard the collection so a client name that has already been recorded is not added
    again, mirroring the guard LoanRepaymentWorkbookPopulator.setNames already has. Each
    client contributes exactly one defined name, whatever its account count; nothing
    changes for tenants that never hit the collision.
  - Apply the same guard to all three affected populators
    (SavingsTransactionsWorkbookPopulator, RecurringDepositTransactionWorkbookPopulator,
    FixedDepositTransactionWorkbookPopulator), which carry identical copies of the loop.
  - Add a unit test per populator: three accounts (client 18, client 19 whose name
    differs from 18's only in case, then client 18 again) reproduce the split-run
    ordering. Each test fails on the unfixed code with the exact production exception and
    asserts one defined name per client, still distinct when upper-cased since Excel
    defined names are case-insensitive.

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

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.

[AshharAhmadKhan]

@oluexpert99 please check the failing log.