Refactor serialization mechanism to be extendable

[beniwohli]

At the moment, our serialization code is just a really long if-elif-elif-... block: https://github.com/elastic/apm-agent-python/blob/ee45d21ff43be495089a005863b7f6af0707fe34/elasticapm/utils/encoding.py#L85-L138.

This has several drawbacks:

• it's not extendable (we e.g. might want to serialize Django QuerySet objects in a sane way that doesn't evaluate the queryset unnecessarily, but only if Django is installed)
• it's brittle
• it's hard to read
• ideally, serialization would also include shortening of values, which is hard to do in its current state

One option could be to have a registry, to which transformers can register themselves, together with a list of supported types for that transformer.

[beniwohli]

As reported in https://github.com/elastic/apm-agent-python/issues/691, if local variable collection is enabled for transactions, evaluating a Django queryset can lead to an infinite recursion.

[kalemas]

python agent fallback to repr() at moment, that is relevant for runtime environment but not useful much whenever you inspect local stack in apm kibana app, for some classes str() would tell more relevant information for post inspection. str() may be ambiguous but supposed to be human readable, and used for printing by default. I know there would be many questionable cases so i do not know how to resolve this without custom serializer.

added later: so point is that neither str() or repr() supposed to be used for post inspection in apm solutions.