* Added Popup for missed skills

* Fixed signal name, reduced Builder and label Popups.

I started refactoring the code to make it easier to follow. This removes some
unused signal, makes some names more consistent and the code a bit easier to
read.

The Game node shouldn't be responsible for updating the party after an
encounter: the party should update itself.

- check press-only mouse (left-button) & touch input events

closes #169

The code has grown pretty complex. Diving back into the battler, rewards, etc.,
I found them hard to work with and some bits weren't logical. E.g. using the
porcupine's experience stat (earned experience) as the player's experience
reward upon killing them!

I missed some of these during code reviews. Anyway that's part of the coding
game: this demo is preproduction work, we have to try ideas and refactor as we
gain experience.

This breaks the rewards at the moment, as they were coupled with the battlers'
stats. It also breaks monsters. I'm opening issues to reflect that.

There's more refactoring to the quest system with this commit. It removes extra
code and scenes.

Quests work from start to finish technically-speaking, although there's more
work left to get the QuestBubble to display properly and to solidify
interactions from the player. I haven't decided yet where to handle that last
part: on the actions themselves or in the QuestSystem.

Now, Quests are the one element that emit signals about their state (started,
completed, delivered).

To use the QuestSystem, you have to get the real quest object in the
QuestSystem's database using the reference scene in the corresponding MapActions.

The quest doesn't pass itself through these signals. If you need a reference to
it on callbacks, you have to bind the quest as the last argument in the connect
method:

```quest.connect('completed', self, '_on_Quest_completed', [quest])```

One of the advantages of this code redesign is that each NPC should only connect
to and track the quest that's referenced in its `[Give/Complete]QuestAction.`
Thus there's no need for safety checks anymore or looping over all existing
quests in the game to find which is active, if it's the tracked quest, etc.

The system's functionality is limited but imo we shouldn't try to create too big
of a system, as we won't have the content to justify it. Now I see how time
consuming a quest system can be, and it'd be easy to go down the rabbit hole
trying to make an advanced one (handling all possible events, cinematics,
spawning npcs or modifying the game world, etc.).

Now we only call Pathfinder.find_path() when clicking on empty cells

To know when an encounter starts and connect to newly created monsters in CombatArena

This is a breaking change. I'm looking for some feedback on how the code feels now.

Quests start but won't complete yet at this point. I
want to do #167 and hopefully #168 as well to simplify the system even more.
Until now it was a pain to just create quests and place them in the game world,
for multiple reasons. E.g. The fact that the GiveQuestAction is inherited in
PawnQuestGiver scenes makes it so the quest reference gets lost every time you
modify the action's script in all instances.

The Journal is also broken right now!

- Made the QuestSystem as a singleton: it had to be passed around multiple parts
  of the game, and probably more and more files as we expand it. I'd rather
  avoid singletons but as the API is limited this has the potential to simplify
  the code IMO
- Devs should now ONLY interact with QuestSystem. The API is a lot simpler:
  start() and deliver() to start and finish quests talking to NPCs. For now the
  rest is handled by the quests internally, based on their objectives.

Removed QuestPawn
Made Quest bubble standalone
Added docstrings to a few nodes

I left some TODO notes for more things to refactor. I think the questsystem api
still has some room for simplification.
Every NPC should also be able to handle quests imo

Quest journal added

Pawns on `local_map` now have a "bubble" on top of them that indicates that they have a quest to give/active/to be delivered by players. 

Works with both:
- Deliver quest to the same NPC that gave it
- Deliver to a different NPC

Gilles explained the UndoRedo object is shared by the entire editor, so another
plugin or function could write to the object in between our do/undo actions,
causing bugs or crashes.

Quest rewards added

I've really got to take some rest 😂

fix wrong node path in DebugInterface

Trying to use Resource to gather all the save data and let Godot store it on the
disk for us
This makes it possible to edit savegames from the inspector
Added a DebugInterface to save and load data, for testing purpose