Bug 24683: Subroutine name changed (fix), no code logic changed This is the intermedi...

Bug 24683: Subroutine name changed (fix), no code logic changed This is the intermediate refactor: renamed subroutine only.

Naming mistake came because this sub is used to detect if anything
available for hold, but it used in "if ANY UNAVAILABLE rule", so actually
results of this sub negated (see below "return" in the code).

In details:

when previous refactor was done, name for subroutine was chosen
wrongly in "opposite" direction from what it actually does:

it was named "ItemsAnyAvailableForHold", but this subroutine gave
truth (1) if at least one of the items available on shelf, not lost,
not on loan, not held, and not restricted by smart rules and damaged
status. So, if this sub says that item is still "available", this
actually PREVENTS item from hold in parent sub (see negated return):

    sub IsAvailableForItemLevelRequest {
        ...
        my $any_available = ItemsAnyAvailableAndNotRestricted...
        return $any_available ? 0 : 1;
             # ^^^ if any available and not restricted - we don't allow
             #     on-shelf holds
        ...

I.e. like it named now: "ItemsAnyAvailableAndNotRestricted".

Small aside fix: white space for '&&' inside brackets added to join
operation by priority visually.

Testing plan not needed: all places where sub used it just renamed.
More: all this places/code was introduced in one older commit so there
is also no overlaps or other calls/uses for this subroutine.

Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 618cf80df9b0b668174b28ff61cad8a938704ec3)

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>