Adds generated test data.

Refs #1.

This introduces `greeter.proto` which includes a simple service for testing purposes. It generates TypeScript declarations and puts them in `generated/`, using TypeScript's `paths` feature to map imports. Karma also needs to map the JavaScript in a similar fashion to resolve itself.

I also refactored the way the `tsconfig.json` files worked to better support this. Now there are three config files which are all a bit different:
* `tsconfig.json` is meant for the editor and contains all TypeScript files (including generated). This allows the IDE to resolve all imports in all files so there are no awkward red squigglies that don't go away.
* `tsconfig.lib.json` is for actually running the compilation. It simply excludes test files, so as not to accidentally use them in a production build.
* `tsconfig.spec.json` is for running tests. It forces a different output directory and format to be compatible with Karma.

One downside of this strategy is that the editor belives all imports are available from all locations which isn't strictly true. For example, `service.ts` should **not** reference Jasmine's `describe()` function, but the editor will not complain about this. In TypeScript 3.9, solution style configs allow for more flexibility in the editor and should be able to better support this format. Filed #3 to look into this when TS3.9 launches.

.gitignore

@@ -1,5 +1,6 @@
 # BXPB
 test-out/
+generated/
 
 # Logs
 logs

packages/bxpb-runtime/karma.conf.js

@@ -11,6 +11,16 @@ module.exports = function (config) {
         karmaTypescriptConfig: {
             tsconfig: './tsconfig.spec.json',
 
+            // Need to manually resolve paths to JavaScript modules.
+            // See: https://stackoverflow.com/a/53605376
+            bundlerOptions: {
+                resolve: {
+                    alias: {
+                        'generated/test_data/greeter_pb': 'generated/test_data/greeter_pb.js',
+                    },
+                },
+            },
+
             // Disable coverage, or else it wraps source files inline and blocks the sourcemap
             // comment from being at the end of the file, thus the browser cannot parse it
             // correctly. By disabling coverage, source maps work as expected.