FINERACT-2778: Allow teller and vault financial activity mappings to be updated

[oluexpert99]

FinancialActivityAccountDataValidator validates the same parameter against two
hand-written lists. validateForCreate accepts all seven FinancialActivity
constants; validateForUpdate accepted five, omitting CASH_AT_MAINVAULT (101)
and CASH_AT_TELLER (102). The platform will therefore create a teller or vault
mapping and then refuse every attempt to change it:

PUT /financialactivityaccounts/{id} {"financialActivityId":102,...}
400 validation.msg.financialactivityaccount.financialActivityId
    .is.not.one.of.expected.enumerations
    must be one of [ 100, 200, 300, 103, 201 ]

Both halves write the same column, and the teller module resolves the mapping
through findByFinancialActivityTypeWithNotFoundDetection whichever route
created it, so the two lists have no reason to differ.

These are the GL accounts the cashier module posts cash against. A deployment
that maps them wrongly, which is easy since they are set once at configuration
time, has every teller and vault movement landing on the wrong account and no
supported way to correct it. The remaining options are to delete the mapping
and create a replacement, discarding the row and its identity, or to update the
database directly, bypassing validation and the audit trail.

FinancialActivityAccountsTest exercised the update path only with
LIABILITY_TRANSFER, and its negative case used activity id 232, which is not in
the enum at all. A value that is in the enum, is accepted by create and is
refused by update fell between the two cases. The test now creates a
CASH_AT_TELLER mapping and updates it.

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.