ensure 'maxResults' limits the number of suggestions too

[jgravois]

i would expect setting maxResults to impact how many suggestions are returned, not geocoding matches.

right now, even though 'L.esri.geosearch' passes along a maxResults parameter when ultimately calling the find operation of the World Geocoding Service, since a magicKey is included too, only one candidate is ever going to come back.

this code change has the desired effect of exposing a technique to augment the number of suggestions returned, but needs a little more testing to make sure all is well with the other providers.

[jgravois]

okay, the PR got a tad sidetracked, but in my testing i noticed we were not handling custom geocoding services well previously at all.

changes/fixes:

1. in addition to checking custom geocoding services to see if they support /suggest, also make a point to fetch alternate singleLineAddressField parameter names
2. use /findAddressCandidates for custom geocoding services when a customParam string is either supplied in the constuctor or fetched by the metadata request above.
3. check to make sure candidates have an extent before trying to utilize it (so we don't bomb out when making requests to old geocoding services
4. throw a console warning and skip firing a /suggest request entirely when the service doesn't support the operation.
5. moved to use 'watch' to rebuild source

in addition to getting tests passing, i confirmed manually that both World and legacy custom geocoders can be used successfully directly via Tasks, from Service methods and from the Geosearch control.

maxResults is honored in suggestions, find/findAddressCandidates calls, and featureServices and mapService queries too.

ready for review.

[jgravois]

this is bogus because people can pass options and still be using the World Geocoding Service.