(iOS) implement the 'quality' property in captureVideo()

[larrybahr]

Platforms affected

iOS

Motivation and Context

iOS 13 records video at 360p https://forum.ionicframework.com/t/media-capture-video-is-low-quality/103774/24

Description

@maxpaj made the changes @jcesarmobile asked for in #48 and #65, but I did not see a pull request so I updated the documentation and am submitting his fix.

Checklist

• [x] I've run the tests to see all new and existing tests pass https://github.com/apache/cordova-plugin-media-capture/pull/65#issuecomment-306416412
• [x] Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• [x] I've updated the documentation if necessary

[larrybahr]

Forgot to push my local change to the repo to fix the build issue. Everything is working now.

[larrybahr]

Any plans to merge?

[larrybahr]

@jcesarmobile I have been using my fork in 2 production apps for months now with no issues. I think this is good to go! Thoughts?

[larrybahr]

@timbru31 so now that jcesarmobile removed their request for review is there anything I can do to help get this merged?

[KGALLET]

+1 needed it too

[psd24]

Hello! Something can be done to be able to launch this PR into production. I think it would be a great improvement to be able to make high quality videos.

[ath0mas]

Previously, no videoQuality was set for pickerController and so it resolved to medium (see doc). Following this plugin default value of 1 for quality is fine but seems to be a breaking change for iOS.

Based on the decisions from #48 and #65, with work of @maxpaj, @jcesarmobile and others we still go for the values 0, 0.5 and 1.

---

I suggest:

1. to remove quality from CaptureVideoOptions.js: this object is only used for windows and in tests, and never expecting quality
2. to make this plugin follow each platform default quality for its own default config/fallback code
   1. update README with distinct Android and iOS Quirks about quality param as it is not available for other platforms, and making it clear that the default value is different between Android and iOS following each native platform defaults
   2. value of 1/High is Android default Seems OK right now: we init and optInt with 1, and then the fallback behavior is resolved by Android itself since we directly pass whatever value the user defined (see ref).
   3. value of 0.5/Medium is iOS default Requires changes on this PR: like

      case 0:
          Low;
      case 10:
          High;
      case 5:
      default:
          Medium;
      

      for explicit 0.5 and fallback to resolve both to Medium + more fallback correctness question in my review added below

[ath0mas]

May be closed as resolved by #214.

[erisu]

I have confirmed that #214 implemented the quality param for iOS and resolved this PR. Closing out this PR as no longer needed. Thank you for the submission.