Event Location fixes

[christianwach]

Overview

The PR goes part way to addressing the issues raised in this Lab ticket.

Before

The issues are succinctly summarised in the OP and in this comment:

After

• LocBlocks are not duplicated
• Address, Email and Phone records are not duplicated
• The "This location is used by..." warning shows correct values
• The "This location is used by..." warning is pluralised

Comments

I have not tested the results of this PR in all possible scenarios but offer it as an improvement on the status quo and a basis for further refinement. I have liberally commented the code in case the changes affect other workflows, e.g. #18586, #18488, #13534 and others I've probably missed.

Not addressed

• "It is not easy to see what other events use that location."
• "Consider whether [the displayed count] is all events, or just active and/or future events"
• "Maybe include a link to search for events using that location"

There is also the question of what happens when, say, an Email field is cleared... is the intent to delete the Email record, or should the record remain as is currently the case?

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[jaapjansma]

test this please

[jaapjansma]

• General standards
  • Explain (r-explain)
    • PASS : The goal/problem/solution have been adequately explained in the PR and on Gitlab.
  • User impact (r-user)
    • PASS: The change would be intuitive or unnoticeable for a majority of users who work with this feature.
  • Documentation (r-doc)
    • PASS: The changes do not require documentation.
  • Run it (r-run)
    • PASS: We created three events all using the same location and we changed the location at one of them and we checked whether it changed at the others. We also checked the notice text about whether the location was in use or not and that looked good to us.
• Developer standards
  • Technical impact (r-tech)
    • PASS: The change preserves compatibility with existing callers/code/downstream.
  • Code quality (r-code)
    • PASS: The functionality, purpose, and style of the code seems clear+sensible.
  • Maintainability (r-maint)
    • PASS: The change is trivial enough that it does not require tests.
  • Test results (r-test)
    • PASS: The test results are all-clear.

@colemanw or @eileenmcnaughton can one of you merge this PR!

[eileenmcnaughton]

Thanks @jaapjansma @christianwach

[eileenmcnaughton]

& Betty too!