Iterator interface for LanguageService

Currently, functions like `LanguageService.getReferencesAtPosition()` or `getNavigateToItems()` return an array. That means, they have to collect all references/navigation items before returning, and blocks the CPU until then. If you invoke such a function in repos like angular/angular the returned array can easily have 50k elements and the function can take a very long time to return. That means a UI can only show the results until all items have been aggregated (of course, you can pass a limit, but in the case of `getNavigateToItems()` that can result in the relevant items you wanted not being found because matching is done fuzzily and the function returns early when `limit` items that matched the query fuzzily were found. For example, in angular/angular, a query for _Http_ with a limit will return a lot of not-relevant `http` variables, but a query without a limit will return the `Http` class). If you have to do more filtering, transformation etc to the items you end up with an unneeded extra iteration. I would like to propose to add or change the API to return an `Iterable` instead. This can be achieved with generators. This would allow the consumer to _pull_ items lazily from the iterator. That means - results (e.g. references, symbols) can be streamed and shown in the UI as soon as they are found in the source - requests can be easily cancelled by aborting iteration (e.g. `break` in a `for of`) - a limit parameter is not needed anymore, you can just abort the iteration after your limit is reached - if you need to perform filtering, transformation etc on the result, you can do that in the same iteration "pipeline" There is no dependency needed to make this work, it's all in the language. The returned Iterable can be consumed in a variety of ways, with `for of`, generator delegation, with iteration libraries or Observables, or easily coverted to an Array with `Array.from()`. This API could be added in a backwards-compatible way by adding a new variant and ch…