Support `inq` splitting in `findByForeignKeys`

Under the hood, inclusion resolvers are implemented using inq operator:

1. Gather PK/FK values from source models.
2. Query target models using inq and PK/FK values from step 1.
3. Assign target models to navigational property in source models.

This can be problematic when the number of source instances is large, we don't
know if all databases support inq with arbitrary number of items.

To address this issue, LB3 is implementing "inq splitting", where a single query
with arbitrary-sized inq condition is split into multiple queries where each
query has a reasonably-sized inq condition.

Connectors are allowed to specify the maximum inq size supported by the
database via dataSource.settings.inqLimit option. By default, inqLimit is
set to 256.

In this task, we need to improve findByForeignKeys (see https://github.com/strongloop/loopback-next/issues/3443) to handle the maximum size of inq parameter supported by the target database (data-source). When the list of provided FK values is too long, then we should split it into smaller chunks and execute multiple queries.

However, because our Repository interface is generic and does not assume that
a repository has to be backed by a data-source, I am proposing to expose
inqLimit via a new property of the Repository interface instead of accessing
the parameter via DataSource settings.

/**
 * Description of capabilities offered by the connector backing the given
 * datasource.
 */
export interface RepositoryCapabilities {
  /**
   * Maximum number of items allowed for `inq` operators.
   * This value is used to split queries when resolving related models
   * for a large number of source instances.
   */
  inqLimit?: number;
}

To preserve backwards compatibility with existing repository implementation, we
cannot add RepositoryCapabilities directly to the Repository class. We need
to introduce a new interface instead that Repositories can (or may not)
implement.

export interface RepositoryWithCapabilities {
  capabilities: RepositoryCapabilities;
}

See #3387 for more details & a prototype implementation.

Acceptance criteria

To allow the helper to detect inqLimit, we need to extend Repository interfaces.

• Introduce RepositoryCapabilities interface (called ConnectorCapabilities in the spike), this interface will have a single property inqLimit (for now).
• Introduce RepositoryWithCapabilities interface (called WithCapabilities in the spike),= this interface should define capabilities property.
• Implement isRepositoryWithCapabilities type guard
• Implement getRepositoryCapabilities helper

The rest should be straightforward:

• Modify findByForeignKeys to obtain inqLimit from repository capabilities and implement query splitting (see the spike implementation).
• Write unit-level tests where we verify what (and how many) queries are called by findByForeignKeys.
• Write integration-level tests (in repository-tests) to verify that connectors can handle inqLimit they are advertising. For example, create a test that runs a query returning 1000 records.

Inizia con findByForeignKeys e le interfacce dei repository, quindi esamina il prototipo a cui si fa riferimento in #3387. Traccia il modo in cui vengono rilevate le capacità dei repository e ispeziona l'area repository-tests prima di aggiungere la copertura dei test unitari e di integrazione. Il lavoro è completo quando esistono helper per le capacità, gli elenchi grandi di chiavi esterne vengono suddivisi in base a inqLimit e viene verificato il numero previsto di query.