feat: fuzon-http implementation

[cmdoret]

Adds a webserver to deploy fuzon as a microservice.
It has the following features:

• load key: ontology pairs (aka collections) from a config file
• cli to provide config file as parameter
• /top endpoint to retrieve top N codes from a collection matching input text
• /list endpoint to retrieve list of collections

[supermaxiste]

praise: code looks clean. I tried to look for small improvements, but the code is simple and very self explanatory. Feels very Groovy somehow ;)
praise: installation works neatly and tool also runs smoothly 🥳

Major

issue: we need to be more transparent with the user about what is going on in the backend.

1. A message stating which ports are exposed is a good start. A full link on how to access the open port is also very helpful, this way users know where things are happening and what is running.

2. A more descriptive Usage section would be best because APIs are hard, especially when there's not a lot of documentation. Breaking down commands and giving examples is always a plus.

3. We build fuzon with modos in mind as use case. How can a dev with a tool similar to modos set up and interact with fuzon via fuzon-http? I feel like having an example use case somewhere in the README would be nice. I'm happy to hear your thoughts

Minor

thought(non-blocking): we're currently hardcoding the port, should that be also part of the config somehow? As mentioned before, as long as we're transparent with the user, we can leave it as is for now.

suggestion(non-blocking): I know the code is not too long, but some unit tests for some of the functions would be great. It can be a separate issue as well.

[cmdoret]

Thanks for the excellent points @supermaxiste

I've addressed your comments except for:

A full link on how to access the open port is also very helpful

I could harcode messages into the code, but I think this would better be done through something like an openapi spec, which can be generated using rust packages (e.g. paperclip). But this is probably too big for this PR.

some unit tests for some of the functions would be great

Simply because most functions require the server to be online for testing and I'm not sure how to do it cleanly, there is prob a way to do this, but I'd rather keep it for another PR.

[supermaxiste]

Very good changes, re-tested everything successfully and all works like a charm 👏

praise: the future-proof API structure is an excellent point I'll keep in mind
praise: README is great and the gif is great ⭐

For the unit tests & the API spec I'll open separate enhancement issues 👍

[cmdoret]

Thanks @supermaxiste indeed, let's tackle #21 and #22 separately 👍