PublicDependencyModuleNames vs PrivateDependencyModuleNames
Controls include paths and defines available to a module
So if A publicly requires B but privately requires C, the Include paths and defines specified by C don't get added to your module when you include A
So if you had a plugin that privately included an SDK's include paths/etc., then including that plugin wouldn't make the SDKs include paths as part of your include paths.
DynamicallyLoadedModuleNames are dynamically linked whereas others are statically/implicitly linked
Explanation of Source Code folder structure
The Public folder is for things that will be exposed from your module. For a game this doesn’t really matter since nothing else will be using it, but it’s important if you ever make an engine or editor module.
The Private folder is for anything that is not exposed. This is all your source files, as well as any header files that aren’t needed by a public interface.
The Classes folder is a semi-legacy thing. This is where the UObject types used to go as it was the only place the UHT would parse. UHT now parses all three folders, so your UObject types can go anywhere now.
All three of these folders are available on the include paths for your module (which is why your include worked after you moved the header to Public). Please note though that things inside the Private folder can only be included by other things inside the Private folder; trying to include something from Private in a Public/Classes header is an error.
If you link to another module via the UBT, only the headers in the Public folder (probably the Classes folder too) of that module will be available to you to include.
If you want to add extra paths in your module to your include paths, you can do this with the PublicIncludePaths and PrivateIncludePaths arrays in your Build.cs file (see ShooterGame.Build.cs).