Update EF Core and extensions packages

- Upgrade EF Core, SQLite, and SQL Server to 9.0.21.
- Upgrade Redis caching and localization abstractions to 10.0.13.
- Leave all other package versions unchanged.

Bump ZiggyCreatures.FusionCache and ZiggyCreatures.FusionCache.Serial…

…ization.SystemTextJson (#82)

Updated
[ZiggyCreatures.FusionCache](https://github.com/ZiggyCreatures/FusionCache)
from 2.8.0 to 2.9.0.

<details>
<summary>Release notes</summary>

_Sourced from [ZiggyCreatures.FusionCache's
releases](https://github.com/ZiggyCreatures/FusionCache/releases)._

## 2.9.0

## 🦅 Eager Refresh now also checks L2

Community member @​sfhb24 noticed that during an Eager Refresh the L2
was not being checked.

Now, this is admittedly not a huge thing per se, because of 2 reasons:
- **backplane:** when using an L1+L2 setup, a
[backplane](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/Backplane.md)
is usually also used, and in that case the factory would not run because
an update on L2 would be immediately visible to the other nodes
- **distributed locker:** by using a [distributed
locker](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/CacheStampede.md#-distributed-locker)
a factory would not run because nodes would coordinate so that only 1
factory runs concurrently, even on multiple nodes

In both these cases, the extra L2 check during an eager refresh would
not be necessary.

Having said that, an L1+L2 setup without a backplane or a distributed
locker may also be common, and in that case the new L2 check in the
eager refresh window can in fact be helpful in reducing the amount of
factory executions even more.

Long story short: I just implemented it!

See [here](ZiggyCreatures/FusionCache#651) for
the issue.


## 🔒 Fix for memory locker + Eager Refresh edge case

If a factory fails when executed in the background during an eager
refresh, FusionCache already takes care of everything and correctly
releases the potentially acquired locks (memory and/or distributed), and
this is good.

But community member @​joaopbnogueira noticed a peculiar edge case: if
the factory is not one marked with the `async` keyword AND it throws an
exception, the memory lock is not being released properly.

Or, to better say, "was not". Because now this has been fixed.

Thanks João for spotting this.

See [here](ZiggyCreatures/FusionCache#647) for
the issue.


## 🔒 Fix for distributed locker + skip L1 edge case

Community member @​joaopbnogueira also noticed another peculiar
scenario, specifically when a `MemoryCache` write fails (yep, it can
happen, true story).

Here's an example of it:
- a custom `MemroyCache` is being used as the L1
- that instance has been configured with a `SizeLimit`
- there's a cache miss
- the factory executes successfully
- the new entry does not have a `Size` specified
- L1 write fails (because with a `SizeLimit` it's mandatory for _every_
entry to specify a `Size`)

In this scenario a distributed lock may not have been released.

But fear no more: this does not hapen anymore!

See [here](ZiggyCreatures/FusionCache#646) for
the issue.


## 🧼 Fix for `Clear(false)` + Fail-Safe
 ... (truncated)

Commits viewable in [compare
view](ZiggyCreatures/FusionCache@v2.8.0...v2.9.0).
</details>

Updated
[ZiggyCreatures.FusionCache.Serialization.SystemTextJson](https://github.com/ZiggyCreatures/FusionCache)
from 2.8.0 to 2.9.0.

<details>
<summary>Release notes</summary>

_Sourced from [ZiggyCreatures.FusionCache.Serialization.SystemTextJson's
releases](https://github.com/ZiggyCreatures/FusionCache/releases)._

## 2.9.0

## 🦅 Eager Refresh now also checks L2

Community member @​sfhb24 noticed that during an Eager Refresh the L2
was not being checked.

Now, this is admittedly not a huge thing per se, because of 2 reasons:
- **backplane:** when using an L1+L2 setup, a
[backplane](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/Backplane.md)
is usually also used, and in that case the factory would not run because
an update on L2 would be immediately visible to the other nodes
- **distributed locker:** by using a [distributed
locker](https://github.com/ZiggyCreatures/FusionCache/blob/main/docs/CacheStampede.md#-distributed-locker)
a factory would not run because nodes would coordinate so that only 1
factory runs concurrently, even on multiple nodes

In both these cases, the extra L2 check during an eager refresh would
not be necessary.

Having said that, an L1+L2 setup without a backplane or a distributed
locker may also be common, and in that case the new L2 check in the
eager refresh window can in fact be helpful in reducing the amount of
factory executions even more.

Long story short: I just implemented it!

See [here](ZiggyCreatures/FusionCache#651) for
the issue.


## 🔒 Fix for memory locker + Eager Refresh edge case

If a factory fails when executed in the background during an eager
refresh, FusionCache already takes care of everything and correctly
releases the potentially acquired locks (memory and/or distributed), and
this is good.

But community member @​joaopbnogueira noticed a peculiar edge case: if
the factory is not one marked with the `async` keyword AND it throws an
exception, the memory lock is not being released properly.

Or, to better say, "was not". Because now this has been fixed.

Thanks João for spotting this.

See [here](ZiggyCreatures/FusionCache#647) for
the issue.


## 🔒 Fix for distributed locker + skip L1 edge case

Community member @​joaopbnogueira also noticed another peculiar
scenario, specifically when a `MemoryCache` write fails (yep, it can
happen, true story).

Here's an example of it:
- a custom `MemroyCache` is being used as the L1
- that instance has been configured with a `SizeLimit`
- there's a cache miss
- the factory executes successfully
- the new entry does not have a `Size` specified
- L1 write fails (because with a `SizeLimit` it's mandatory for _every_
entry to specify a `Size`)

In this scenario a distributed lock may not have been released.

But fear no more: this does not hapen anymore!

See [here](ZiggyCreatures/FusionCache#646) for
the issue.


## 🧼 Fix for `Clear(false)` + Fail-Safe
 ... (truncated)

Commits viewable in [compare
view](ZiggyCreatures/FusionCache@v2.8.0...v2.9.0).
</details>

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>