fix: export types independent of @types/request

[JustinBeckwith]

I'm not 100% if this is the right answer, but here we go. This change drops the dependency on @types/request, and exports its own set of types to be used by consuming clients.

The primary reason for doing this comes from here:
googleapis/nodejs-common#392

• Since this module didn't export it's own types, consumers need to install @types/request
• Some of the request interfaces are directly exposed in public methods. As a result, @types/request needed to be installed as a dependency instead of a devDependency
• Folks run npm ls, and see that a @types package leaked into their production code

The secondary reason is being explicit about which fields are supported and not supported. While the goal is compatibility with request, we have seen cases (like the forever flag) where a feature was missing, but the types provided by @types/request tell the user everything is fine. It would be nice to use the type system as a way to signal what is and isn't specifically supported.

I can't really think of an alternative approach that doesn't lead to leaking these packages into production builds. Would love to hear others thoughts!

@ofrobots @benco @fhinkel @alexander-fenster @stephenplusplus @callmehiphop

[bcoe]

I like this change:

1. we're no longer using this library as a drop in replacement for Request in our libraries, so I think inheriting its types is less necessary.
2. it's a pain to have to keep in step with request, given .1.