Introduce a generic HistoryRepository service without changing storage or caching

We should consider compatability with #2006632: Make HISTORY_READ_LIMIT configurable.As long as we don't add @api to our new HistoryRepositoryInterface, we can add future methods to it related to #2006632: Make HISTORY_READ_LIMIT configurable, according to the core BC policy for interfaces.

OK, I've worked in various changes now. Key features:

1. I've added a Kernel test. Yaay!

2. I've settled on this for the API:

  public function getTime(EntityInterface $entity, ?AccountInterface $account, ?$default);
  public function getTimes(string $entity_type, array $entity_ids, ?AccountInterface $account, ?$default): array;
  public function setTime(EntityInterface $entity, ?AccountInterface $account, ?int $time): HistoryRepositoryInterface;
  public function setTimes(string $entity_type, array $entity_ids, ?AccountInterface $account, ?int $time): HistoryRepositoryInterface;

This doesn't support for reading or writing entities from multiple entity types in one database transaction, but that's not possible in this case for writing anyway with Drupal's upsert or merge queries, and I'm unsure anyone will ever need it for reading anyway. I considered supporting multiple entity types in one api call, but it adds a lot of complication to the code.

I'm strongly in faviour of including the account as a parameter here. I'm less concerned about including time but it seems harmless and even helps testing.

3. history_read_multiple() defaults to returning 0 as a time if an entity has no history. This is a dubious piece of API design as 0 is a valid time, and I'm not fond of continuing to force that choice on users of this API What I've done is allow callers to specify the default value they'd like. If they don't specify, or specify NULL, then entities for which we have no history are excluded from the array returned by getTimes(). I dislike the complexity of this and welcome discussion on it.

4. history_read_multiple() uses static caching. I've replicated this in order to avoid a hypothetical performance regression. However, it adds significant complexity and I'm unsure many sites are making repeated calls for history on the same entity in the same request. If we can get this committed without this caching, I'm in favour of removing it from here and deferring it to #3267020: Use caching for history.

Sorry I dropped this one. After the work I did here, I reviewed more the histpry of #2081585: [META] Modernize the History module and realise that I did various things wrong here that did not fully reflect proper consideration of things already discussed in the parent issue.

Especially

(1) the static caching code I put in place to avoid using MemoryCache is simply a mistake. I thought it would be better to avoid MemoryCache to keep things simple in this issue, BUT history_read_multiple already has static caching so we can't do that. When I try to add in static caching in the repository service, the result is so complex it would be better to use MemoryCache

(2) I really didn't like the fact that we defaulted to zero as the last read time if there was no read history, which seems bad because zero is actually a valid unix time. However this adds complexity and has tricky BC issues.

Overall, I think this MR should actually be a lot closer to the last patch in the parent issue, just without the code to update the storage to work with non-node entity types.