Fix EZP-22775: Handle missing API Limitations better

Issue: https://jira.ez.no/browse/EZP-22775

## Originally approach
In #851 there was an attempt to solve the problem by catching the exceptions in Repository->hasAccess() and assume that user does not have access under the current policy and continue iterate to the next one. However this does not benefit use of RoleService (incl userhash generation++), where the exceptions are still the case and this can't be solved by silencing it (as you then loose the whole role in question as exception is thrown instead).

## New approach
Creates:
- A Blocking Limitation(Value) & LimitationType  (think Null FieldType, but instead of doing nothing always says no)
- A MatchNone Criterion
- Sub classed NotFoundException to LimitationNotFoundException to provide more information on how to solve in the exception message (we should do the same on field types)

The idea is that you can configure missing limitations to map to BLockingLimitation, which will by design make it clear you don't have access under the given policy, also when querying using MatchNone, as we can't possible know without actually implementing the Limitation.

#### Benefit
Avoid exceptions on Limitations with no implementation that we don't really care about in New stack as they are not planned to be used. Example: ezjscore FunctionList limitation (configured out of the box here)

<del>#### Open question
I have kept the catch clause in Repository->hasAccess() as added in #851, as it benefits pure usage of API (with exception of RoleService), however on the other side it hides missing configuration so can be argued to be removed to make this behave 100% like missing FieldTypes where you need to configure NullType.</del>
<ins>Decided to remove this to make it consistent</ins>

I'd just remove the phpdoc altogether. A ctor always creates an instance of the class.