refactor: rework Entry, Request and Response classes

[betaboon]

I'm sorry, this went a "little" overboard 🙈

So I am opening this PR as a draft, to discuss with you what you think.

I refactored the entry, request and response classes to be ABCs and went from there.

This gets us to almost fully typed, introduces new apis, but keeps all old apis available and cleanly marked as backwards-compat.

I have no good idea to split this up in multiple sensible commits.
I split this PR intro (hopefully) easy to follow, individually working commits.

[coveralls]

coverage: 97.727% (-1.0%) from 98.68%
when pulling a69d07e on betaboon:refactor-entry
into 9cfad4c on mindflayer:main.

[coveralls]

coverage: 97.385% (-1.3%) from 98.68%
when pulling 218eb32 on betaboon:refactor-entry
into 9cfad4c on mindflayer:main.

[sonarqubecloud]

Quality Gate failed

Failed conditions
2 Security Hotspots
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[betaboon]

fyi i have another branch that builds on top of this that gets us to fully typed.

[mindflayer]

I'm sorry for not answering before, first I've been sick, then very busy at work. I'll look at both soon.

[betaboon]

Nothing to be sorry. feel better and take your time :)

[mindflayer]

I am not sure I like the concept of mocket.core, in the end it gets most of the code, not very different from having it under mocket.
If you want to make it tidier, maybe something like mocket.decorators for decorators, etc.

[mindflayer]

MocketBytesResponse can be created with bytes/str/bool? Isn't it confusing?

[mindflayer]

I've read the code a bunch of times already, and I have the feeling that Mocket APIs got more complicated than they were before, instead of being simpler and cleaner.
Correct me if I am wrong, maybe I just missed the point here.
It would have been easier if you started from documenting the ideas behind it.