TISTUD-6930 Content Assist: Alloy: Show Object instance methods for $

We have an extension mechanism which resolves the alias between $ and the actual controller type 
The controller type is computed as shown below . We now record all identifiers with the controller type 
as the owning type. Additionally we now create a type element corresponding to the controller type and set its 
owning type as the Global type

1./app/controllers/index.js -> IndexController 
2./app/controllers/a/index.js ->AIndexController 
3./app/controllers/a/bc.js -> ABcController 
4./app/controllers/ab/c.js -> AbCController

![screen shot 2014-10-01 at 2 53 13 pm](https://cloud.githubusercontent.com/assets/8658904/4527517/bd39eed4-4d67-11e4-8a3a-dd4182cb4a41.png)

![screen shot 2014-10-01 at 2 53 48 pm](https://cloud.githubusercontent.com/assets/8658904/4527522/c7a35f22-4d67-11e4-94c3-74e1b656fa1a.png)

![screen shot 2014-10-01 at 2 54 06 pm](https://cloud.githubusercontent.com/assets/8658904/4527529/d0091cd8-4d67-11e4-8f8f-9e3324e68106.png)

![screen shot 2014-10-01 at 2 54 27 pm](https://cloud.githubusercontent.com/assets/8658904/4527533/d6d5c624-4d67-11e4-8949-2961801cdf1f.png)


Instead of lazily grabbing all resolvers and immediately instantiating them, why don't we instantiate them on-demand here in the loop, so we avoid instantiating all of them if say the first once gives us a result and we never visit the others? Also, I don't think there's any reason to keep them in memory in a List forever, since they're only used when we resolve. 
Clearly this needs to be balanced by performance issues if we're doing this repeatedly while indexing, we don't want to keep instantiating and then GCing the same instances. So maybe keeping them around in memory is much better.
In fact, you may want to add more properties/enablement expressions as a means of avoiding doing any work instantiating anything unless we know that a resolver applies to the current situation. Basically I'm worried because if we're doing in type inferencing in JS, it's going to be called a _lot_ by our code.

So we want to avoid instantiating resolvers we never use, but balance that by making this operation as fast as possible. Typically that's done by doing some pre-filtering/enablement checking on extensions to avoid instantiation unless they're used (i.e only on alloy projects), and to instantiate lazily - but then often by caching the instantiated items if we're constantly re-using them.