Fix various typos and wording in Language Service Internals docs (dotnet#12788)

Author: dawedawe

docs/fcs/caches.fsx

@@ -18,7 +18,7 @@ Each FSharpChecker object maintains a set of caches.  These are
 
 * ``scriptClosureCache`` - an MRU cache of default size ``projectCacheSize`` that caches the 
   computation of GetProjectOptionsFromScript. This computation can be lengthy as it can involve processing the transitive closure
-  of all ``#load`` directives, which in turn can mean parsing an unbounded number of script files
+  of all ``#load`` directives, which in turn can mean parsing an unbounded number of script files.
 
 * ``incrementalBuildersCache`` - an MRU cache of projects where a handle is being kept to their incremental checking state, 
   of default size ``projectCacheSize`` (= 3 unless explicitly set as a parameter).  

docs/fcs/react.fsx

@@ -16,7 +16,7 @@ FCS is an incremental execution engine. The aim is to make it Roslyn-like. We're
 
 There are two dimensions of incrementality:
 
-* The inputs change, e.g. the source filed are edited or a referenced assembly changes, appears or disappears
+* The inputs change, e.g. the source files are edited or a referenced assembly changes, appears or disappears
 * The results of analysis on the inputs (e.g. a parse tree) are further enriched with information (e.g. symbol uses are requested) and this information is held, i.e. not re-computed, perhaps by a returned object.
 
 The logical results of all "Check" routines (``ParseAndCheckFileInProject``, ``GetBackgroundCheckResultsForFileInProject``, 

docs/tooling-features.md

@@ -17,7 +17,7 @@ The following tables are split into two categories: syntactic and semantic. They
 |  Action                                | Data inspected | Data returned | Expected CPU/Allocations (S/M/L/XL) |
 |----------------------------------------|----------------|---------------|-----------------|
 | Syntactic Classification               | Current doc's source text | Text span and classification type for each token in the document | S |
-| Breakpoint Resolution                  | Current doc's syntax tree | Text span representing where breakpoing where resolve | S |
+| Breakpoint Resolution                  | Current doc's syntax tree | Text span representing where breakpoints were resolved | S |
 | Debugging data tip info                | Current doc's source text | Text span representing the token being inspected | S |
 | Brace pair matching                    | Current doc's source text | Text spans representing brace pairs that match in the input document | S |
 | "Smart" indentation                    | Current doc's source text | Indentation location in a document | S |
@@ -74,5 +74,5 @@ Most actions are `S` if they operate on cached data and the compiler determines
 
 For example, commands like Find All References and Rename can be cheap if a codebase is small, hence the lower bound being `S`. But if the symbol in question is used across many documents in a large project graph, they are very expensive because the entire graph must be crawled and all symbols contained in its documents must be inspected.
 
-In contrast, actions like highlighting all symbols in a document aren't terribly expensive even for very large file files. That's because the symbols to be inspected are ultimately only in a single document.
+In contrast, actions like highlighting all symbols in a document aren't terribly expensive even for very large files. That's because the symbols to be inspected are ultimately only in a single document.