…les on CI

Previously, only e2e tests were run for docs examples on CI. As a
result, unit tests (which are included in the zipped archives we provide
for users to download and play with the examples locally) were often
outdated and broken.

This commit configures specific docs examples that have meaningful unit
tests to run them on CI (via the `run-example-e2e.js` script). Where
necessary, the unit tests are fixed to ensure they pass and reflect the
changes in the corresponding component/service.
This commit also removes some auto-generated unit tests that are not
meaningful (e.g. make trivial assertions, such that a component instance
is truthy) and are often broken anyway (e.g. because the corresponding
component has been changed in ways that make the tests fail).

…`core-js`

The `core-js` dependency is no longer included in `package.json` for
`cli`-type examples, but only for the `systemjs` ones. This commit
updates the `package.json` templates to reflect that (and also updates
the `npm-packages` guide accordingly).

… `tests`

Each docs example has an `example-config.json` configuration file. Among
other things, this file can be used to specify what commands to run in
order to test the example. (If not specified, the `run-example-e2e.js`
script will run a default `yarn e2e` command.)

Previously, the property specifying the test commands was called `e2e`.
This is because in the past only e2e tests were run for docs examples.
Since recently, some examples may specify commands for other types of
tests (such as unit tests). Therefore, calling the property that holds
the list of test commands `e2e` no longer makes sense and can be
misleading to people looking at the configuration files.

This commit renamed the property to the more generic `tests`. In the
future, the `run-example-e2e.js` script (and corresponding npm script)
should be renamed and refactored to also avoid giving the impression
that only e2e tests are run.

Discussed in:
angular#36143 (comment)

…s example ZIP archive

Previously, the `package.json` template used in the ZIP archive of the
`universal` example that we offer for download missed the `build` npm
script.

This commit updates the template for the `universal` docs example to
include the `build` npm script.

NOTE:
The `build` npm script is already included in
`aio/tools/examples/shared/boilerplate/universal/package.json`, but it
was removed by the example zipper.

I noticed these minor styling issues while aligning the `universal`
examples with the `toh-pt6` example (in a subsequent commit).

…match latest CLI

Update the `main.ts` files in Tour-of-Heroes examples to match what
would be generated by the latest CLI.

As mentioned in the `universal` guide, the `toh-pt6` examples is the
starting poitn for the `universal` example. However, the two examples
had become out-of-sync, because some fixes/changes were made to the
Tour-of-Heroes examples.

This commit ports these changes to the `universal` example.

Update the `universal` example (and related files) to match what would
be generated by the latest CLI.

… error in `universal` example

Previously, building the `universal` example failed with:
```
node_modules/@types/express/index.d.ts(90,50): error TS2694: Namespace '".../@types/express-serve-static-core/index"' has no exported member 'Params'.
node_modules/@types/express/index.d.ts(90,64): error TS2694: Namespace '".../@types/express-serve-static-core/index"' has no exported member 'ParamsDictionary'.
```

This commit fixes the error by upgrading
`@types/express-serve-static-core` to a newer version.
See DefinitelyTyped/DefinitelyTyped#40905 for more details.

Previously, there were no tests for the `universal` docs example. This
meant that the project was not tested at all (not even ensuring that it
can be built successfully).

This commit adds e2e tests for the `universal` example (ported from
`toh-pt6` and cleaned up) and also verifies that the project can be
built successfully (including the server).

In the past, server-side rendered apps needed to convert URLs used in
API requests to absolute when rendering on the server. Originally, this
was handled in the `universal` guide and corresponding example app by
modifying the `HeroService` to use `APP_BASE_HREF` to derive the
absolute URL.

In angular#28956, the guide was updated to show an improved method: Specifying
an `HttpInterceptor` that took care of converting the URLs to absolute.
That interceptor was only provided when rendering the app on the server.
By mistake, the corresponding example app was not updated along with the
guide.

Since `@nguniversal/*` v7.1.0, it is no longer necessary to convert the
URLs to absolute inside the app. This is handled in the `@nguniversal`
libs (see angular/universal#897).

This commit updates the example app to emove unnecessary code and
modifies the guide to mention the issue with absolute URLs, but explain
that developers only need to worry about it when not using one of the
`@nguniversal/*-engine` packages.

Update the `i18n` example (and related files) to match what would be
generated by the latest CLI.