media plugin update, fixes #4734 and other issues

# media plugin updates #
## Issue ##
During debug my discovery was that the _src_ **attribute** is always being applied to the <video> element even when the field is left blank:
![1-src-left-blank](https://f.cloud.github.com/assets/552329/254424/b012d874-8bf3-11e2-814b-93005b41ad3b.png)
... and we leave it blank because we want to specify two alternative video sources for the different browser implementations so we use the <source> **elements** instead.  We find them under the next tab, the Advanced tab:
![2-source-elements](https://f.cloud.github.com/assets/552329/254442/25e578f4-8bf4-11e2-8403-574abbac1347.png)
It is important to note the differences between the _**attribute**_ and _**element**_ usage here because the HTML5 specs state that ...

> There are two ways to specify a media resource, the src attribute, or source elements.
The attribute overrides the elements.
[Resource](http://www.w3.org/TR/html5/embedded-content-0.html#location-of-the-media-resource)

... and although we are leaving the src attribute blank and assigning the source elements you can see in the Source tab that our code shows the incorrect/invalid markup:
![3-html-source](https://f.cloud.github.com/assets/552329/254462/92ab635e-8bf4-11e2-8cf2-960cb65aa64a.png)
## Recovery ##
data.video.sources[0] is causing all our problems.  We should just use the _src_ attribute if it exists on our <video> element.  Then _data.video.sources_ will contain an array of <source> values, as it should be, without the <video> _src_ attribute mixed in with the rest of the <source> elements array.  By changing this logic I was able to resolve [bug #4734](http://www.tinymce.com/develop/bugtracker_view.php?id=4734)
Then when the HTML is rendered in the source tab (or by using the HTML source edit icon) I noticed that the callback routine to convert the img element to code was not working properly.  I discovered that line 460 of the plugin /media/editor_plugin.js source is our issue:
    if (!sources[0].type) {
There never is any _type_ attribute so I'm guessing it is an old carryover from previous code that was going to try and add the _type_ attribute.  I think we are better off letting the server provide the mime type and we won't worry about it for now.  If we decide to add it later to the TinyMCE media plugin, that's fine.  We can still separate the <video> _src_ attribute from the <source> elements which is much better and easier to troubleshoot and maintain.
Lastly, we need to add "object" to the HTML5 <video> valid_elements array.  Actually, <video> could have any child element if I understand the current [W3 specification properly:](http://www.w3.org/TR/html5/embedded-content-0.html#the-video-element)

>Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents.

So I added "|object" in the tinymce_src.js.  Well, actually it is in the Schema.js file.  Otherwise when parsing the html TinyMCE states that <object> is not a valid child of <video> (invalidChildren is set) as you can see during debug:
![video-issue](https://f.cloud.github.com/assets/552329/254553/df49487e-8bf5-11e2-9130-9fc397d8f28d.png)

I think that about wraps it up.  I tried not to include any whitespace updates to make your diff comparison easier but it looks as if that didn't happen.  My apologies!

Todd
(aka coopster on your Forum)