feat: Get the award content for an offer from the award service

[berkes]

This implements step 5 and 6 from the
https://www.educredentials.eu/ec-issuer/import_in_wallet.html feature.

ec-issuer gets award from ec-award
ec-award returns award to ec-issuer

Furtheremore, this commit includes refactorings to keep consistency across services and their usage. Now that the offer-service calls another service, consistency between those two matters.

---

@153957 We've previously agreed that I would make thomas at least aware of some changes to this service because that's a gradual and pragmatic way to "hand over" and to "introduce" them into this codebase. I've therefore assigned you as reviewer here. Reviewing is mostly "for your info", so that you can see what kind of work is done in this repo and how it is done.

@ThomasKalverda This makes a nice example of how we:

• build a module (screaming architecture)
• use the ports/adapters + service for such a module
• use the test system to test stuff on unit, integration and e2e level. Though nothing changed in e2e, because no behaviour changed.

Both: it also shows how ports/adapters can work in Python. What it, IMO, shows very well, is the immense amount of boilerplate and abstractions to do a thing that's in essence very simple: Make a http call to a service and use the json thereof in another call to another service.
In other words: I think it shows us quite well how "un-pythonesque" this setup really is. I am not even close to a python expert, so I'm a poor judge. But I think it shows that this architecture doesn't agree well with Python and vice-versa.

Because, if we boil it down to the very essense, we now need over 1000 lines of code changed, for what could have been one simple

award = request.get(os.environ["AWARDS_SERVICE_URL"]).json()

If we ignore or not require tests, typing, error-handling, and a layered/enterprice architecture ;)

I come from rust (and some Java and C# and such) where layering abstractions is common and tooling and language features handle a lot of what we must write "by hand" in python. I think part of the "un-pythonesqe-ishness" comes from me, implementing the abstractions wrong. But I think the largest part comes from the requirement to have such an "enterprise-architecture" in a language/ecosystem, python, that's the antithesis of "enterprice".