feature: Add a new backend method to fetch puppet (character) info

We factorize code with the previously defined function `get-player`,
thanks to the `get-resource` function. As for the terminology,
`character` suffers the same limitation of `map`, hence we have to
rename it. On the one hand, `map` became `scene`, on the other hand
`character` becomes `puppet`.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
refactor: Simplify the `get-player` function

The previous function was basically taking care of two different
things: (1) an asynchronous HTTP request, and (2) JSON parsing. This
patch divides this function into three, more focus simpler ones. As a
result, it is both more readable, and potentially easier to turn into
a reusable macro for future backend functions.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
feature: Provide a new package :lb to fetch persistent resources

Currently, the only function the :lb package provides allows for
retrieving a player description in an asynchronous manner. The main
idea is to perform HTTP request, so that the backend can be
implemented in another process, potentially in another language.

Here is a straightforward use of #'lb:get-player:

     (lambda ()
       (lb:get-player "lthms" :then #'print)))

A good way to provide a dummy (yet working) HTTP server is to use the
`http.server` module of python 3:

    python -m http.server 4001

The current implementation expect to find players in a `player/`

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
feature: Clean up daemon state when a player closes its socket

When a player closes its socket, we need to (1) remove its socket from
the daemon list of players sockets, and (2) remove the player from its
instance. When an instance becomes empty, we need to “kill” it. We do
that by telling its pool it should be killed, via the ~frame-step~
function, by returning ~t~ (true).

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
chore: Ignore fasl files

It may happen that Slime generates fasl files. I am not completely
sure why, but we can safely ignore it.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
feature: Introduce a generic step function called every step

Every ~dt~ seconds, the ~frame-step~ function is called for each
instance currently spawned by the daemon. If an instance returns
~nil~, this means it should be its last frame.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
chore: Start logging using the vom package

Contrary to the Elixir implementation, we will try to log as many
information as possible. Currently, we just warn when we register a
new player, and when we create a new instance because all the already
existing ones are already full.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
feature: Spawn new instances of a single scene on demand

This patch introduces several key concept of the lycan daemon. The
game is organized on a set of interconnected scenes. It is possible to
set a limit for the number of players allowed on a given scene
simultaneously. In case a new player wants to register to a scene
which is already full, the daemon will spawn a new instance for this
scene. Note that the current implementation still lacks of a key
feature: killing empty instances.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
refactor: Rename ~game~ into ~daemon~

There is no notion of gameplay in the current implementation, only a
very straightforward players management. The gameplay will take place
into the map instances, probably with some kind of ECS
pattern. Therefore, the name ~daemon~ is more precise and describes
better the role of the class.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>
chore: Introduce an asynchronous Lycan implementation

The first implementation was an actor-based implementation written in
rust. The second implementation follows the same principle, but is
written in Elixir. On the contrary, this third prototype will be based
on an event loop, to implement more easily a client-server
reconciliation logic.

In addition to this asynchronous aspect, this allows for sharing the
game logic implementation between the client and the server.

The project will be released under the terms of the APGLv3.

Signed-off-by: Thomas Letan <contact@thomasletan.fr>