Updated Doc/ with grammar fixes (#120)

* Update CodeStyle.md with more grammar

I'm trying to get into this project, just noticed some grammar jank with the dev instructions so I thought I'd fix a few while reading the file.
Might look over the other files too.
This ruleset is strict, but this project which will force me to code a bit less like a stream of vomit if I end up working on it so that's good.

* Update ModuleSystem.md

* Update DeveloperGuide.md

* Update CodeStyle.md

Co-authored-by: Asuka <bingkan@outlook.com>

Doc/CodeStyle.md

@@ -41,8 +41,8 @@ And based on the above Sony's style, we add the following extra rules, to make o
    e.g. functions which have more than one `if` statement.  
 
    Many people don't used to this pattern, but over the years, I only see one disadvantage of it, that is: when there's a loop in the function and you want to directly return the function within the loop, you need to define an extra flag variable to store whether or not the return condition was met. But with this only disadvantage, it brings many good things:
-   1. First and most important, this pattern force the code grows vertically, not to expend horizontally and nested again and again, because when condition not match, you just break. This way the code is more easier to read and maintain.  
-   2. "One function one return" together with "do while false" makes sure, the function only has one exist point, thus you can release any resources right before the return, thus reduing things you need to remember in your mind, and remember things as less as possible is good for programming. I know there is RAII for C++, but you wouldn't like use RAII on all resources, that would require more extra code.
+   1. First and most important, this pattern forces the code to grow vertically, not to expend horizontally and nested again and again, because when a condition does not match, you just break. This way the code is more easier to read and maintain.  
+   2. "One function one return" together with "do while false" makes sure the function only has one exit point, thus you can release any resources right before the return, thus reducing things you need to remember in your mind, and remember things as less as possible is good for programming. I know there is RAII for C++, but you wouldn't like to use RAII on all resources, that would require more extra code.
    3. It also helps people to figure out the most important part of a function, this is called *Guard Clauses*. Once you are used to it, you know what appears at the begining of a functions is just some bad condition checks which is less important, saving time again.
 
     For examp;e:
@@ -171,7 +171,7 @@ And based on the above Sony's style, we add the following extra rules, to make o
 4. Do not write a function longer than your sceen's height. Typically 50-80 lines at most.  
    Some table type functions not included, like a big `switch` statement.
 
-5. Add brace to `if`, `while` statement even if it has only one line of code followed.
+5. Add brace to `if`, `while` statements even if it has only one line of code followed.
 
 6. Do not use magic numbers directly, give it a meaningful name.
 
@@ -208,4 +208,4 @@ And based on the above Sony's style, we add the following extra rules, to make o
 
 
 PS1: Third party library code is not limited by the above rules.  
-PS2: Forget about some old Hungarian notation style code, I'll fix that once I have time.
+PS2: Forget about some old Hungarian notation style code, I'll fix that once I have time.

Doc/DeveloperGuide.md

@@ -24,22 +24,22 @@ Build steps:
 
  
 ## Run demos/games:
-Currently, GPCS4 need a path of main elf/bin as input parameter, and will redirect all `app0` access to the `Current Working Directory`.  
+Currently, GPCS4 needs a path to the main elf/bin file as input parameter, and will redirect all `app0` access to the `Current Working Directory`.  
 ie. `/app0/shader_vv.sb` to `E:\Code\GPCS4\Debug\shader_vv.sb`  
 
 Follow the steps:
-1. Checkout a proper branch, the master branch is under heavy development and maybe not stable for test.
+1. Checkout a proper branch, the master branch is under heavy development and maybe not stable for testing.
 2. Extract `lib` from [your download](https://pastebin.com/bUxckm3y) to the folder where your game is located.
 3. Open properties window of GPCS4 project in Visual Studio, switch to Debugging tab,  
 set `Working Directory` to your game's folder.  
 set `Command Arguments` according to the help message, ie. `-E eboot.bin`.   
-Note you don't need to specify the full path because the `Working Directory` has been set to the folder the elf/bin locate.
+Note you don't need to specify the full path because the `Working Directory` has been set to the folder that the elf/bin located.
 4. Build the `x64 Debug` version and press F5.
 
 Note, if you want to test the graphics part, currently I've not implemented constant buffers, so you need to 
 `#define SCE_GNMX_ENABLE_GFX_LCUE 1` before building any demos.
 
-## For short term bug fix & feature add:
+## For short term bug fixes & feature additions:
 Read our [code style document](https://github.com/Inori/GPCS4/blob/master/Doc/CodeStyle.md), then just make a pull request, we'll see.
 
 
@@ -47,7 +47,7 @@ Read our [code style document](https://github.com/Inori/GPCS4/blob/master/Doc/Co
 
 ***Make sure you have enough free time to do this job. Don't just have a brief period of enthusiasm. This is the most important part.***
 
-Note, before you write any code, read our [code style document](https://github.com/Inori/GPCS4/blob/master/Doc/CodeStyle.md) carefully, code which do not follow the style will not be accepted.  
+Note, before you write any code, read our [code style document](https://github.com/Inori/GPCS4/blob/master/Doc/CodeStyle.md) carefully, code which does not follow the style will not be accepted.  
 Also, you can take the existing code as examples.
 
 Follow the steps:

Doc/ModuleSystem.md

@@ -10,7 +10,7 @@ To be done...
 
 ## Rules of Module Loading and Linking
 
-One thing that may confuse newcomers is that the emulator does not treat virtual and native modules equally. The virtual modules are somehow the first-class citizens in the GPCS4, which are preferred by the module system, and all of them get loaded before the game executable is loaded. The native modules, on the other hand, are loaded on-demand after the loading of the game executable, so we use the term "**override**" to describe the module system uses an implementation from a native module instead of a virtual module.
+One thing that may confuse newcomers is that the emulator does not treat virtual and native modules equally. The virtual modules are somehow the first-class citizens in the GPCS4, which are preferred by the module system, and all of them get loaded before the game executable is loaded. The native modules, on the other hand, are loaded on-demand after the loading of the game executable, so we use the term "**override**" to describe the way the module system uses an implementation from a native module instead of a virtual module.
 
 ### The Overridability Switches