And remove the unused isomorphic fetch dep.

Introductory import of the Apollo Link core, common and HTTP
code that is going to be integrated into the Apollo Client core.
This code is going to change, but this commit gets the initial
code moved over, and ensures that all Link tests still pass.

Now that the HTTP link code is part of AC, we can open up the
constructor to allow additional options, like Apollo Boost did.
Most people will just want to use `uri`, but `credentials`
and `headers` use is common enough that it probably makes
sense to expose them as well. Other HTTP link options can
still be accessed by instantiating an `HttpLink` and passing
it in via AC's constructor `link` option. Defining a custom
link overrides the `uri`, `credentials`, and `headers` options.

The Apollo Link project will be updated to re-use common and
HTTP based link code from Apollo Client, so we need to make
sure that code is reachable externally.

This util was adding very little additional value over just using
`ApolloLink` directly.

Also removes link test utilities from the public API.

This should help make future refactoring a bit easier, and gets
us away from re-exporting all link utility functions, when very
few of them need to be made available outside of this project.

Smaller, more focused files should make it easier to refactor
AC's link support further. Link based re-exports from Apollo
Client have been adjusted at the same time, to make sure we're
only exporting items that are trully needed by 3rd party links
(and by the `apollo-link` repo).

I'm not sure what the historical reason was for exposing link
utility functions like `concat`, `empty`, `from`, `split` and
`execute` both as static functions on `ApolloLink` and as
separate importable functions. Since it might be a bit jarring
for people if we remove one of these options, for now lets
move all `ApolloLink` functionality back into the `ApolloLink`
class, and instead re-export that functionality as separate
utility functions. Using the utility functions through
`ApolloLink` seems to be the most popular approach, and by
aligning this in the code we'll make future maintenance a bit
easier.

Sub-classing then re-exporting `Observable` leads to the
`@types/zen-observable` types not being available, when
`Observable` is exported from `@apollo/client`. This is because
the `@types/zen-observable` class declaration
(`declare class Observable<T>`) is replaced during TS
compilation with the `class Observable extends LinkObservable`
declaration, which doesn't expose any of original
`Observable` methods. This means projects like Apollo Link
that are using the re-exported `Observable` from
`@apollo/client`, don't see any of the `Observable` methods
when using Typescript.

Instead of creating an `Observable` sub-class with the additional
RxJS interop functionality, this commit uses TS global module
augmentation to essentially add to the `@types/zen-observable`
`Observable` type. It then adds the needed interop function to
`Observable` directly. This allows external projects like
Apollo Link to find all `@types/zen-observable` types, and
keeps RxJS interop functionality in place.

And just to add - method creation using `$$observable` was
removed as `zen-observable` already does this:

https://github.com/zenparsing/zen-observable/blob/f63849a8c60af5d514efc8e9d6138d8273c49ad6/src/Observable.js#L396

Make sure all parts of Apollo Client import `Observable`
from a local module, instead of from `zen-observable`
directly. This decoupling will make things easier as we
investigate letting people use their own observables
implementation.