Use drop chance correctly

Given that `randf` output is in the range [0, 1] inclusive, and we want `chance = 0` to mean never, and `chance = 1` to mean always, we need to worry about the edge cases.

We need the `>=` because when `randf() == 0` and `chance == 0` just using `>` would give us the wrong result.

We need to compare against 1 because when `randf() == 1` and `chance == 1` we would get the wrong reasult due to the `>=`.

This is the from I found easier to read.

Fixed dialogue path

The dialogue forlder was moved in 426a3b18

Update gitignore file

Fix comment-reformatting spillover

Fix #190: Enabling Pixel Snap

Level up on experience change; fixed type mismatch

* 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.).