[SPIKE] Patron block limits BE needs redesign or facade for FE

Patron block conditions and limits APIs were implemented in MODUSERS-174 and MODUSERS-177.

Two entities were created - patron block conditions and patron block limits.

Patron block condition defines which actions should be blocked for a patron if this condition is met.

Example of a patron block condition (now there are 6 of such objects, hardcoded, created at mod-users module initialization):

{
  "id": "72b67965-5b73-4840-bc0b-be8f3f6e047e",
  "name": "Maximum number of lost items",
  "blockBorrowing": true,
  "blockRenewals": true,
  "blockRequests": true,
  "valueType": "Integer",
  "message": "The maximum number of lost items has been reached"
}

Patron block limit is set for a patron group. Limit's value is used to determine if condition is met.

Example of a patron block limit (created for each patron group):

{
  "id": "1de95200-72e4-4967-bdf8-257fb7559536",
  "patronGroupId": "ac502f9e-a611-4644-8a8c-a5bb9768a7f6",
  "conditionId": "72b67965-5b73-4840-bc0b-be8f3f6e047e",
  "value": "10"
}

The idea was that patron block limit object is only created when limit for patron group is set by user.
For example, there may exist only 4 patron block limit objects for a particular patron group because other 2 weren't set.

In UIU-1167 FE team needs to implement a form to create/update these limits.

Currently this is what the flow should be:

To print the form:

1. Call GET /patron-block-conditions to get the list of conditions
2. Call GET /patron-block-limits for a particular patron group (filter by patronGroupId) to get limit values (may not include values for all of the conditions)
3. Show a form, fill in the existing values

To save the values:

1. For each of the existing limits call PUT /patron-block-limits/{id}
2. For each of the new limits call POST /patron-block-limits/{id}

FE team is saying that there's no UI component currently that can handle this. They need an API that would allow to make a single GET call to fetch all required data and a single POST/PUT call to save the data.
Possible solutions:

1. Include limits in the patron group object. May cause issues in the future if this functionality needs to be reused for some other kind of limits, f.e. location limits.
2. Provide facade for FE.