Delete dart2js_resolver and fix some typos in README

pkg/compiler/README.md

 # The dart2js compiler
 
 Welcome to the sources of the dart2js compiler!
 
 ## Architecture
 
 The compiler is currently undergoing a long refactoring process. As you navigate
 this code you may find it helpful to understand how the compiler used to be,
 where it is going, and where it is today.
 
 ### The near future architecture
 
 The compiler will operate in these general phases:
 
   1. **load kernel**: Load all the code as kernel
       * Collect dart sources transtively
       * Convert to kernel AST  
   
-  (this is will handled by invoking the front-end package)
+  (this will be handled by invoking the front-end package)
   
-  Alternatively, the compiler can start compilation directly from a kernel
-  file(s).
+  Alternatively, the compiler can start compilation directly from kernel files.
 
   2. **model**: Create a Dart model of the program
      * The kernel ASTs could be used as a model, so this might be a no-op or just
        creating a thin wrapper on top of kernel.
 
   3. **tree-shake and create world**: Build world of reachable code
      * For each reachable piece of code:
          * Compute impact (i1) from kernel AST
      * Build a closed world (w1)
 
@@ skipping 166 matching lines @@
     growing, in the past the term *universe* was used to describe this growing
     world. While the term is not completely deleted from the codebase, a lot of
     progress has been made to rename *universe* into *world builders*.
 
   * **model**: there are many models in the compiler:
 
     * **element model**: this is an abstraction describing the elements seen in
       Dart programs, like "libraries", "classes", "methods", etc.
 
     * **entity model**: also describes elements seen in Dart programs, but it is
-      meant to be minimalistic and a super-hierarcy above the *element models*.
+      meant to be minimalistic and a super-hierarchy above the *element models*.
       This is a newer addition, is an added abstraction to make it possible to
       refactor our code from our old frontend to the kernel frontend.
 
     * **Dart vs JS models**: the compiler in the past had a single model to
       describe elements in the source and elements that were being compiled. In
       the future we plan to have two. Both input model and output models will be
       implementations of the *entity model*. The JS model is intended to have
       concepts specific about generating code in JS (like constructor-bodies as
       a separate entity than the constructor, closure classes, etc).
 
     * **emitter model**: this is a model just used for dumping out the structure
       of the program in a .js text file. It doesn't have enough semantic meaning
       to be a JS model for compilation at this moment.
 
   * **enqueuer**: a work-queue used to achieve tree-shaking (or more precisely
     tree-growing): elements are added to the enqueuer as we recognize that they
     are needed in a given application. Note that we even track how elements are
     used, since some ways of using an element require more code than others.
 
 ### Code layout
 
-Here are some details of our current code layout and what's on each file. This
+Here are some details of our current code layout and what's in each file. This
 list also includes some action items (labeled AI below), which are mainly
 cleanup tasks that we have been discussing for a while:
 
 **bin folder**: some experimental command-line entrypoints, these need to be
 revisited
 
 * `bin/dart2js.dart`: is a dart2js entry point, not used today other than
   locally for development, most of our tools launch dart2js from
   `lib/src/dart2js.dart` instead.
 
   AI: change how we build the SDK to launch dart2js from here, most logic might
   remain inside `lib/src/dart2js.dart` for testing purposes.
 
-* `bin/resolver.dart`: an experimental binary we used to run the resolver and
-  serializer. As we are moving to work on top of kernel this is deprecated and
-  should be deleted.
-
-  AI: delete this file.
-
 **lib folder**: API to use dart2js as a library. This is used by our
 command-line tool to launch dart2js, but also by pub to invoke dart2js as a
 library during `pub-build` and `pub-serve`.
 
 * `lib/compiler_new.dart`: the current API. This API is used by our command-line
   tool to spawn the dart2js compiler. This API (and everything that is
   transitively created from it) has no dependencies on `dart:io` so that the
   compiler can be used in contexts where `dart:io` is not available (e.g.
   running in a browser worker) or where `dart:io` is not used explicitly (e.g.
   running as a pub transformer).
@@ skipping 190 matching lines @@
 * `lib/src/mirrors_used.dart`: task that analyzes `@MirrorsUsed` annotations,
   which let the compiler continue to do tree-shaking even when code is used via
   `dart:mirrors`.
 
 * Input/output: the compiler is designed to avoid all dependencies on dart:io.
   Most data is consumed and emitted via provider APIs.
 
   * `lib/src/compiler_new.dart`: defines the interface of these providers (see
     `CompilerInput` and `CompilerOutput`).
 
-  * `lib/src/null_compiler_output.dart`: an `CompilerOutput` that discards all
+  * `lib/src/null_compiler_output.dart`: a `CompilerOutput` that discards all
     data written to it (name derives from /dev/null).
 
   * `lib/src/source_file_provider.dart`: _TODO: add details_.
 
 * Parsing: most of the parsing logic is now in the `front_end` package,
   currently under `pkg/front_end/lib/src/fasta/scanner` and
   `pkg/front_end/lib/src/fasta/parser`. The `front_end` parser is AST agnostic
   and uses listeners to create on the side what they want as the result of
   parsing. The logic to create dart2js' ASTs is defined in listeners within the
   compiler package:
@@ skipping 84 matching lines @@
   * `invoke_dynamic_specializers.dart`
   * `builder.dart`
   * `ssa_branch_builder.dart`
   * `value_range_analyzer.dart`
   * `ssa_tracer.dart`
   * `loop_handler.dart`
 
 * `tool`: some helper scripts, some of these could be deleted
 
   * `tool/perf.dart`: used by our benchmark runners to measure performance of
-    some frontend pieces of dart2js. We shuld be able to delete it in the near
+    some frontend pieces of dart2js. We should be able to delete it in the near
     future once the front end code is moved into `fasta`.
 
   * `tool/perf_test.dart`: small test to ensure we don't break `perf.dart`.
 
   * `tool/track_memory.dart`: a helper script to see memory usage of dart2js
     while it's running. Used in the past to profile the global analysis phases
     when run on very large apps.
 
   * `tool/dart2js_stress.dart` and `tool/dart2js_profile_many.dart`: other
     helper wrappers to make it easier to profile dart2js with Observatory.
@@ skipping 236 matching lines @@
 `lib/src/types/forwarding_type_mask.dart`
 `lib/src/types/container_type_mask.dart`
 `lib/src/types/constants.dart`
 `lib/src/types/flat_type_mask.dart`
 `lib/src/types/masks.dart`
 `lib/src/types/value_type_mask.dart`
 `lib/src/types/union_type_mask.dart`
 
 `lib/src/hash`
 `lib/src/hash/sha1.dart`