All sorts of changes, fixes, optimizations, and cleanup

[EComes-DigiPen]

Please carefully look over all changes I've made. Some prominent ones include:

• Using smaller and/or unsigned variable types (short, char, etc.) for things such as gamepad IDs, screen and window resolution, image size, RGB color, etc.
• Frame count is now an unsigned long, which ensures that a CProcessing game/project/program at 60 frames per second can run for the foreseeable future
• Added MIT license to all applicable file headers (including ones that previously had "INTERNAL USE ONLY" in them, that is now gone)
• Consistent presence of assets between both the sample and empty solutions
• Somewhat consistent code style and formatting (using some Visual Studio plugins, namely StyleCop and CodeMaid, along with manual changes)
• Replaced release ZIP files with highly-compressed 7-Zip (.7z) files.

[ianelsbree]

Hi there, just wondering why you have added all of the image assets including the justin1.png and justin2.png images to the Processing_Empty release, as that seems like a release that should have fewer assets loaded with it relative to the Processing_Sample release.

[EComes-DigiPen]

Hi there, just wondering why you have added all of the image assets including the justin1.png and justin2.png images to the Processing_Empty release, as that seems like a release that should have fewer assets loaded with it relative to the Processing_Sample release.

Since I assumed that those assets are intended to be used as placeholders when developing a project, I figured that it wouldn't hurt to include them in the Processing_Empty project. One can remove them if they don't need or want them.

[AEllinger]

I haven’t had time to go through the whole thing in detail, but I wanted to make a few comments.

First, thanks for putting the effort into doing this! We appreciate people engaging with the project, whether or not we end up using all your contributions.

• Some of your changes for smaller data types might make sense, but let me touch on why we don’t always use the smallest type possible. Optimizing for memory usage like this used to be more important but isn’t usually very relevant on modern computers. Also, for computer architecture reasons, it is generally slightly faster to use types that match the native size of the processor, either 32 or 64 bit. So even though it is wasteful of memory, often we would rather optimize for speed and use integers.
• As a note on assets, we did deliberately have some files in our test program that we did not include in the empty project for students.
• Without getting into arguing about styles (tabs vs two spaces vs four spaces can get heated, as an example), as part of a change like this we would want to make sure that we did not change any files from the libraries such as nanovg.
• 7-Zip files may be more compressed, but they are less convenient for users, and we are not dealing with files that are large enough for a bit more compression to matter.

[justinchambers-dp]

Spoke with EComes and requested changes be split up to avoid hiding things under all the whitespace and formatting changes. There have already been excellent responses to items brought up in this PR, but I'll add some quick notes to confirm our stance:

• We prefer type simplicity for user interfaces (int and float) especially for those new to programming
• We will stick with tabs in our files and retain the style of any included libraries
• .zip for compressed files to maintain maximum user compatibility

Closing this PR in anticipation of updated changes.