Completely rework field/overworld movement code

[food-please]

I've never been fully happy with the movement code for the overworld characters. The main issues were that:
a) It was very complicated, which makes it hard for newcomers to understand and adapt the demo. This was exacerbated by imperfect design (looking back, there was lots to clean up) and heavy use of the physics engine (which had a number of edge cases that required odd solutions, such as when two gamepieces tried to move onto the same cell at the same physics tick, since the physics state doesn't update until the next physics frame).
b) There were a number of bugs, mostly also related to the physics engine. The player might find sometimes that they couldn't move to a cell that they should have been able to move to.

The following is from the changelog:

This update has aimed to greatly simplify the code responsible for moving Gamepieces around the Gameboard, while keeping the structure of the code roughly the same. Most scripts dealing with the overworld/field gamestate have been changed, but the main features are as follows:

• Collision on the Gameboard is no longer based on physics-based collisions. The physics implementation was great, but introduced a host of edge cases (e.g. two gamepieces moving onto the same cell on the same physics tick) that had to be accounted for.
• Rather, objects used to build the pathfinder use a registry pattern; GameboardLayers register themselves with the Gameboard, and Gamepieces register themselves with the GamepieceRegistry. The board and registry update automatically based on signals from their registered objects, and the user no longer needs to worry about emitting global signals such as "FieldEvents.terrain_changed". It all happens under the hood.
• The removal of circular dependency issues that were present in early Godot 4.X has made life much easier. The Gameboard singleton allows anything to figure out where coordinates occur on the gameboard and if those coordinates are moveable (thanks to the single Pathfinder), and the GamepieceRegistry allows objects (cutscenes!) to easily find where everything and everyone is placed on the board. Gameboard and GamepieceRegistry are autoloads that allow designers to easily observe the global overworld state without having to worry (too much) about messing things up.
• Many objects have had their responsibilities reduced, such as Gamepiece which now only deals with moving to a point (rather than also tracking cells, coordinates, movement paths, etc.), and GamepieceControllers which now are much more focused on helping a gamepiece follow a path in response to player and AI input (as opposed to previously, where they also dabbled in pathfinding, physics shenanigans, etc.)
  Overall, the code should now be simpler to understand at first glance, and much easier for newcomers to work through. Happy designing!

Basically, I've tried to simplify the code by making it much easier to follow. The Gameboard is built from TileMapLayers that have the GameboardLayer script attached. These layers may all be stacked on top of each other. These layers have an IsCellBlocked property painted onto the tileset. Cells that are blocked are not used for pathfinding. Importantly (and differently from the previous structure), the designer doesn't have to do anything to effect the change with the pathfinder, since the Gameboard is connected automatically to these layers and changes the pathfinder on the fly via Godot's signals. An example of this is seen with the "suspicious tree" interaction, where the player walks around a tree to find a key.

The GamepieceRegistry keeps track of where all gamepieces are. Similar to GameboardLayers, any time a Gamepiece changes its cell in the registry the Pathfinder is automatically updated. Previously, there was some work for the designers to sync everything up, especially if they were implementing new controllers (for example, a controller for party gamepieces following the player is on the dock, and should be much easier to implement now).

The important thing about this registry paradigm is that Gameboard and GamepieceRegistry perform all of their updates in response to signals, so they are also autoloads that allow designers to observe the gamestate without needing to pass a host of references around or without being able to easily "mess up" what's going on under the hood. It also means that there's much less going on. There's only one Pathfinder now, and all it does is find paths. Gamepieces don't have to worry about their movement paths, since they're only concerned about moving their animations around. Maps can have a much more fluid structure, since systems aren't looking for objects in specific parts of the scene tree. Etc.

Anyways, I hope that this update is worthwhile and simple to follow. Please let me know any thoughts or questions or feedback that you may have.

[food-please]

I had cloned the most recent main branch, but for whatever reason it sill is trying to bring old commits (those from f1675c0 and before). Sorry about that, I'm not quite sure how to remove those.

This also probably supersedes this PR, since basically everything about the overworld has changed.

[NathanLovato]

Thank you very much once again for the hard work! Please don't worry about the other commits being carried into the pull request. I'll take care of them.

Lately my focus is once again on writing our course curriculum. So it might take me a little bit of time to get to this. But rest assured I've taken note of the PR in my todo list and I'll review and merge this as soon as possible.