add more common types

[jgravois]

porting a whole load of interfaces and types originally written by @JeffJacobson 🎉

AFFECTS PACKAGES:
@esri/arcgis-rest-common-types
@esri/arcgis-rest-geocoder
@esri/arcgis-rest-groups
@esri/arcgis-rest-items
batch-geocoder

BREAKING CHANGE:
no longer prefacing interface names with an I

maybe its just the ArcObjects phobia talking, but 5 minutes into this port i started to agree with @tomwayson. A quick look at the TypeScript Language Specification made it clear that its not a universally agreed upon convention.

i'm planning on tackling #104 soon so it makes sense to me to rip off the proverbial esri-loader band-aid here too and just release a 2.0.0 if everyone else agrees.

for now, the associated linter rule is turned off because we're still using the I outside common-types.

[coveralls]

Coverage remained the same at 100.0% when pulling 73ce0b8 on moar-types into 52caf83 on master.

[patrickarlt]

@jgravois @tomwayson while prefixing interfaces with I isn't a universal standard by any means (it is borrowed from .Net) but think it makes sense to differentiate between classes in the JS API Extent, Point, SpatialReference and Item and the interfaces that we use in these libraries, IExtent, IPoint, ISpatialReference and IItem.

I would hate to end up with something like this:

import { Extent } from "@esri/rest-js-common-types";

require(["esri/Extent"], (Extent) => {
  // now you have 2 problems...
});

Prefixing with I quickly tells you that the thing you are looking at is an interface and not a class. Just because the TypeScript Guidelines discourage it is no reason not to do since the guidelines are for contributing to TypeScript not writing TypeScript code in general.

It also seems a little silly to push 2.0.0 over something so minor.

[tomwayson]

I don't feel too strongly one way or the other about the I prefix, but I think @patrickarlt makes a salient point about the name collisions w/ the JSAPI classes. I'm pretty sure you could get around that by importing as, but why make it harder on people (other than @jgravois) than it already is.

[tomwayson]

TIL - you can have line breaks w/in ${} in template literals w/o adding line breaks to the output.

[tomwayson]

If we don't rename the existing interfaces, then this would not have to be a breaking change, right?

If not, I say we lump these in w/ either a 1.0.3 release, or a 1.1.0 release w/ #115

[tomwayson]

I think we want to remove this now that we're back to Iing everything, right?

[jgravois]

definitely. fixed.

[tomwayson]

This LGTM now, so merge and include in 1.0.3, or wait for 1.1.0?

[jgravois]

merge and include in 1.0.3, or wait for 1.1.0?

I'm fine with either. i just want to make sure and include #120 in v1.0.3

[tomwayson]

If 1.0.3 is eminent, I'd say let this be the first PR of 1.1.0