Switch to Vcpkg manifest

[HexDecimal]

Not perfect, it seems Visual Studio needs the vcpkg integrate install command. I've updated the README.md with Vcpkg instructions.

Vcpkg manifest includes: breakpad, libtcod, PDCurses, and SDL2. I've also setup the curses project to use Vcpkg if you want to ever start debugging that.

Pinned manifest to the current latest Vcpkg revision. Manifest mode and "builtin-baseline" is the secret ingredient to stable dependencies.

Including modern libtcod headers will fail until #22 is merged, for reasons explained in #12.

[HexDecimal]

I'm more familiar with setting up Vcpkg for CMake than for MSBuild. The way I've set it up here makes it easy to add a CMake build later on, for cross-platform builds. I can get started on that after this PR if it's a priority.

This adds a Vcpkg submodule next to the vcpkg.json file. The Vcpkg baseline is very strict. The baseline combined with GitHub Actions shallow by default checkouts means that the baseline must match the submodule revision exactly. You will need to pull or fetch on your local Vcpkg repo to make the baseline setting happy, it wants a very exact, very recent revision.

This updates to the latest version of libtcod. I've discovered an issue where modifier keys will stick if TCOD_console_init_root is called while they're held. The current code does not respond to window exposed events.

[rmtew]

Can we get rid of the submodule? I am very anti-submodule. I have spent way too much time trying to deal with corrupt submodules.

[HexDecimal]

The Vcpkg repo needs to be cloned for CI and later on CMake, any alternative is just a submodule with extra steps which will be less supported and more error prone than a submodule.

In most cases cloning the submodule will be optional. CMake will need it for CI again, but can be configured to use a local repo instead.

I've heard some criticism of submodules before, but it's usually about how it doesn't vendor the target repo, how did you manage to get yours corrupted?

[rmtew]

I don't know. But it is very hard to fix without deleting the whole parent repo as it keeps coming back. My belief is that this is a layer of unnecessary abstraction that adds problems of it's own and replaces simple standard commands to little benefit.

[HexDecimal]

There's some abstraction, but eventually you learn that internals of Git are actually rather simple, or at least, you learn about how the abstractions work and that makes them less surprising to use.

Can I at least assure you that adding a submodule is reversible? The tracked files of submodules are only the .gitmodules file and the "abstract" file which stores the commit hash the submodule is checked out at which becomes the folder for that sub-repo.

I also really want to know what you were doing with submodules that was causing issues. I've done a lot with Git to put myself into unfixable situations, which were no longer unfixable once I became more experienced. What was your goal when you were using submodules?

[rmtew]

What is the benefit in using submodules? Surely not using them wouldn't take that much time or add that much work.

[HexDecimal]

Good locality, standard, easy to manipulate. Even if you haven't personally shared that experience I find them convenient to work with, which is why I keep asking for more information about your previous issues working with them since even I had issues of my own when I first started using submodules. I want to know because many solutions to a lot of Git issues are both simple and obscure.

Not using submodules means spreading the sub-repo info throughout the repository and adding friction to manipulating the target commit and local testing of alternative Vcpkg ports. I don't think is this worth avoiding submodules for.