fix getLinkTarget for MEI 5 work titles

[bwbohl]

Description, Context and related Issue

Remove mei:titleStmt when determining the title of the work because in MEI 5 mei:title is a direct child of mei:work
Closes #337

How Has This Been Tested?

With a BAZ-GA MEI 5 work.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Overview

• I have performed a self-review of my code, according to the style guide

• I have read the CONTRIBUTING document.

• I have added tests to cover my changes at testing

• All new and existing tests passed.
  --> will know when the PR has run its tests ;-)

[peterstadler]

Only from looking at it (i.e. without testing) that looks ok. Yet I wonder whether the whole conditional is overly complicated and something like //work//title[1] for every case would be enough?
Otherwise it would be very helpful to have some inline documentation that records the motivation for the different cases.

[krHERO]

at the community meeting 2024-12-18 we agreed to add inline documentation regarding MEI versions for the v1.0.0 release @bwbohl and to have a more complex solution in a later release

[bwbohl]

Ok, I tried to simplify and globalise a bit in the local:getWindowTitle. For a later release we definitely have to revisit all object assumption and put those in corresponding XQuery modules, e.g. work.xqm also was a work:isWork function but the assumptions there are not identical to those in getLinkTarget.xql, that’s why I did not use it for now.

@riedde please test with your dataset that has mei:work as root elements in your work encodings. I heavily reduced that bit of the function because $doc//mei:work is true for all the cases we had before. I introduced a worhTitleContainer variable to deal with the MEI versions.

[roewenstrunk]

Rebased locally and tested with Klarinettenquintett and Pintos