The content_security_policy property in the manifest is only for the extension background, pop-up, and iframe pages. It does not apply to content scripts or to pages that the extension acts on.
Only one extension can modify a request's headers at a time, so relying on modifying Gmail's CSP headers will cause the extension to break if the user has another extension modifying CSP headers (a few extensions like Tampermonkey modify all request CSP headers!). There is a better solution. Extension content scripts are allowed to bypass the page CSP rules in general, though there's a few cases you noticed that are currently bugged (cross-origin script tags and frames). Though your extension script does not get the ability to bypass CSP rules if it's injected into the page, because then to Chrome it's indistinguishable from Gmail's scripts.
Instead of having your extension content script add a script tag to the page with a remote URL, just do an AJAX request to load the script and then eval the contents. This will cause the downloaded script to be run as an extension content script instead of a page script, and the page's CSP rules in general won't affect its execution. It also means that you don't have to share your javascript context with Gmail or other badly-behaving extensions!
To work around iframes being blocked by the page's CSP rules: it turns out that iframes loaded from chrome-extension:// URIs are never blocked by Chrome, so whenever you want your extension to inject an iframe with a remote URL into the page, instead inject an iframe with a URL to an html file inside your extension (and then that iframe will be obeying the extension's content_security_policy instead of Gmail's, and you can have that contain a full-sized iframe to a remote URL).
Some of the above is discussed on this Chrome bug: https://code.google.com/p/chromium/issues/detail?id=391128