* Fixes Issue #1140

Fixes https://github.com/react-native-community/react-native-webview/issues/1140
Based on a solution found at: https://stackoverflow.com/questions/56460362/how-to-force-wkwebview-to-ignore-hardware-silent-switch-on-ios
I changed the code found in the linked source from Swift to Objective-C, as required by this project. WARNING: I haven't used Swift before and very limited experience with Objective-C.

- For me this seems to work, but it is not the cleanest solution in my opinion.
- It might also be possible to play generated sound (i.e. using oscillator) instead of hardcoding the silent base64 mp3 data.
- Maybe ignoring silence switch should only be done if a parameter is supplied

* fixes import path

* adds documentation for ignoreSilentHardwareSwitch

* adds ignoreSilentHardwareSwitch parameter

* reverting back to old import path

* Update Guide.md

Co-authored-by: Dominik Beste <dominik.beste@gmail.com>

BREAKING CHANGE: 
• Props updates to `injectedJavaScript` are no longer immutable.

• `injectedJavaScript` no longer attaches a `jsEvaluationValue` property to the `onLoadingFinish` event. Check out: https://github.com/react-native-community/react-native-webview/pull/1119#issuecomment-574919464 to migrate with the same behavior.

* Don't show camera options for a file upload that would result in nothing happening for the user.

On Android, if the application declares the camera permission, then even intents
that use the camera require permission to be granted. This is a problem for apps
that combine an in-app camera with a WebView that has file uploading and the user
has not given permission for the camera.

Note, this will not request permission for camera. This will simply prevent
showing the camera options that would be a no-op action for users. It does this
by checking if the camera permission is declared, and if so, checks that the
user has granted permission.

More information: https://blog.egorand.me/taking-photos-not-so-simply-how-i-got-bitten-by-action_image_capture/

* Add example and documentation about camera option availability in file uploads for Android.

BREAKING CHANGE: if you use onNavigationStateChange on iOS it will now trigger on # changes to the url.

* Hook the `window.history` API on iOS to generate events

The underlying WKWebView doesn't seem to generate any events in response to the `window.history` API - none of the `WKNavigationDelegate` methods fire.

Given this limitation, the only way to know when the location changes via this API is to inject Javascript into the page and have it notify the native code directly when any of these functions are called.

The `setTimeout` call gives up the current tick, allowing the location to change before firing the event.

* Remove the outdated section about hash changes

Now that this bug is fixed, the workaround is no longer required.

* Run the injectedJavaScript on DocumentStart for iOS

* Add new prop injectedJavaScriptBeforeContentLoaded
Update types
Update docs

* Self review

Fixes #746 

These steps are based on my other project React native draftjs which requires loading a local HTML file. The code can be found in the following line - bc51410117/index.js (L113)

[skip ci]

* Added guide for working with custom headers and cookies

* Remove extraneous files

Apple required us to remove this (see #819)

BREAKING CHANGE: UIWebView has been removed
BREAKING CHANGE: useWebkit prop removal
BREAKING CHANGE: scalesPageToFit prop removal on iOS (since it's not compatible with WKWebview)
BREAKING CHANGE: Renamed RNCWKWebView to RNCWebView on iOS

* Added guides for communication between React Native and web pages

* Updated Guide a bit

* Adds guide for handling navigation state changes

* Update Guide.md

Addresses #80.

Caveat: I am not an Android developer. This code comes from a fork of the original RN WebView that we have been using in production for some time, so all credit goes to @Oblongmana: https://github.com/Oblongmana/react-native-webview-file-upload-android.

Setting up a DownloadManager for the WebView is pretty straightforward, as is adding any known cookies to the request. Most of the complication comes from the requirement after SDK 23 to ask the user for the WRITE_EXTERNAL_STORAGE permission. Unfortunately there is no mechanism to suspend the download request until permission is resolved so this code stores off the request and sets up a listener that enqueues the download once permissions are resolved so the user experience is really nice.

I didn't see anything in the way of tests or documentation that needs to be added for this change, so let me know if I missed anything. Thanks!

Fixes #33 

I could really use some help from an Android developer on this one, because I just "made it work", don't know how to "make it work good".

Some things that should be reviewed:

- [ ] validate Android 5.0 devices (my emulator work, but outputs some weird sounds; a Galaxy 4 I tested on crashes)
- [ ] validate Android 5.1 devices (emulator works, couldn't find a real device)
- [ ] how to handle File Extensions? (https://www.w3schools.com/tags/att_input_accept.asp)

I'm sure that there's more refactoring to be done, so any help and advice would be appreciated.