Implementation decoupling

- Motivation 

This change is motivated directly by my integration and usage of the library in my app (Ra).  I try to do as much console-based testing as I can, including my presentation layer (presenters / view-models / controllers / etc).   However, I am facing the issue that more and more of my libraries need to import ace.dart, and the transitive import on `dart:js` for the proxy code will not run in that environment.

As a secondary motivation, this makes a cleaner separation of the `proxy` and `pure dart` implementations, and swapping them out in the future when the latter matures will be a one-liner.  It also gives a clear hook for a mock implementation, for that console-based testing story.

- Usage impact

I've tried to minimize the impact on the user as much as possible, but in order to achieve the goal the application code must be responsible for wiring the implementation (at least in today's dart).  This should be a 1-liner in the bootstrapping code of an application:

```dart
import 'package:ace/ace.dart' as ace;
import 'package:ace/proxy.dart';

main() {
  ace.implementation = aceProxyImplementation;
  ...
}
```
This should be the only file where you `import 'package:ace/proxy.dart';`; all of your other files will only `import 'package:ace/ace.dart' as ace;` like before and they should continue to function with no breakage and with the _bonus_ of being testable!

@devoncarew @umop please let me know if you guys have any concerns or other feedback on this

thanks!