Discuss whether to deprecate serialization string casting bc layer before 9.x

Problem/Motivation

#2751325: All serialized values are strings, should be integers/booleans when appropriate → was committed with an opt-in backwards compatibility layer to retain the current behaviour of outputting everything as a string.

However there are two reasons we might not want to maintain that bc layer:

1. In general, casting issues are due to having to cast '1' to 1 (For comparisons and similar), often in tests. It's much less likely that a client would get an integer and choke on it because it had previously got a string. We also expect it to be a quick update for clients if they do run into a problem.

2. If we need to change output again, we'll have two bc layers, instead of two output variants, this will give us four:

1. No bc layer
2. BC layer 1 only
3. BC layer 2 only
4. BC layer 1 + BC layer 2

That problem will get worse if there was a third issue too.

Proposed resolution

Consider a deprecation notice if the bc-layer is enabled (add it to 8.3.x or 8.4.x) and then remove the bc layer in 8.4.x or 8.5.x. This gives clients a 6-12 month window to update if they need to, without maintaining a potentially redundant and/or progressively more complex bc layer for years.

Remaining tasks

User interface changes

API changes

Data model changes