Mxml/intellisenseimprovement

As the commit description says:

- Added event completion support. Decided to make matches lookup more relaxed than the one in other IDEs.
- Added function type completion support.
- Added Inspectable metadata support. This required some global ActionScript metadata parsing improvements.

Regarding the first point: other IDEs just look for functions with a single argument that has a compatible event type, inside the current class. I look for all compatible functions (ie: functions with more than one argument where the others are not mandatory, functions where the first argument type is also Object or *, matching public and protected functions from parents...). Event handler creation is not supported at this moment.

About the third point: current FD metadata support is way incomplete (not that FD ever had more use for it anyway), as a lot of metadata is ignored and incorrectly appended to the file model while metadata can be defined for most object types. I only added Inspectable metadata support, so there are stil a lot of metadata tags not processed, but, again, they are not being used inside FD. To solve the second issue I extended MemberModel and added a MetaData property and when parsing source files I don't store the metadata in the model until we get what object type it supplements, for now, only functions and variables, although I haven't checked this: maybe after the big switch the current member is stored and metadata can be appended to anything as it should? at any rate, it's enough as it is right now.
I don't understand that from the article, it says it would be overkill to use a separate StringBuilder for something like 'entry[0] + "=\"" + entry[1] + "\""'. Quoting it:

"The important difference between this example and the previous one is that we can easily present all the strings which need to be concatenated together in one call to String.Concat. That means that no intermediate strings are needed. StringBuilder is efficient in the first example because it acts as a container for the intermediate result without having to copy that result each time - when there's no intermediate result anyway, it has no advantage. "

In order to get rawParams we need intermediate strings as metadata can have an indeterminate amount of parameters. I think we're going on an useless discussion loop heh. Would be nicer to get the opinion from some .NET eminence, but surely the answer would be that in this case it wouldn't make much of a difference to use one or the other approach.