Better hunt for Wrapper or InLine tags (with XPath). Just taking the first Element leads to not working when the first element is, for example, an XML comment!
Including the already contained Impressions in a videoAd — e.g. when we're in an InlineAd which is coming from a Wrapper.
Merge branch 'refs/heads/master' into vast2
Including the already contained clickTrackingURLs in a videoAd — e.g. when we're in an InlineAd which is coming from a Wrapper.
A Wrapper VAST 1 in contrary to a Wrapper VAST 2 or an InLine (VAST 1 or 2) has the <VideoClicks> in its root instead of in the Video Tag.
Tracking impressions before playing — also allows to track impressions of Ads not playing a media file (e.g. Fallback)
Only tracking "start" and "complete" for ads that play media file.
Most events (play, firstQuartile, midPoint, thirdQuartile, complete) shouldn't be tracked more than once. Since we can however receive more than call for them I decided to use this (given, somewhat uncool) workaround.
Ensure that trackImpressions (the only context sent as a NSMutableArray) are only sent once by removing a URL once reported by NSURLConnection.
Using removeObject would produce a "mutating while enumerating in some circumstances" — setting to NSNull produces the same effect without the crash :)
The previous commit didn't completely fixed the case where it would crash. This will, since we're not enumerating anymore.
Removing the observer once "processed", avoiding to trigger twice the Ad.
In some cases (that I cannot explain) apparently we get this crash

*** Terminating app due to uncaught exception 'NSRangeException', reason: 'Cannot remove an observer <DVIABPlayer 0x1ecb7ee0> for the key path "rate" from <DVIABPlayer 0x1ecb7ee0> because it is not registered as an observer.'

Wrapping the removeObserver in a @try@catch will fix it — but it's weird.
In rare cases it seems that the ad "arrives" once the content video is already playing (probably something to do with network lag or asynchronicity). In this "worst case" we'd better pause the content player (which will be restarted once the ad has finished playing).
Only removing the observer if it's actually there. Happened in very few cases, probably people tapping very fast on the "close" button before the video started playing.
Avoid crashing if tracking URL is invalid/empty by first checking.
Merge branch 'vast2' of https://github.com/grandcentrix/ios-vast-player

Signed-off-by: Bilge Ulusoy <bilge.ulusoy@me.com>

Conflicts:
	DVVAST/Classes/DVVideoAdServingTemplate+Parsing.m