Add verboseness to FileSelectionCanceledError

While working on an application, I needed a plugin that would work well cross-platform. I found this one to be most fitting.
I also found that it is most likely that you were going to get a straight up FileSelectionCanceledError exception, regardless of the underlying exception. This is kind of an issue, especially on the Android platform. Permission denials will cause that exception to come up. This means a developer using this plugin may need to resort to vagueness just in case a user denies a permission that the plugin requires for that platform.
I don't seem to be alone in regards to the exception. Issues #31 & #34 also point out the issue.

I decided to write up a little fix to the issue.

Example of how it would be handled...

void importFile(context) async {
    await FilePickerCross.importFromStorage().then(() {
      // ...
    }).onError((error, _) {
      String _exceptionData = error.reason();
      print('----------------------');
      print('REASON: ${_exceptionData}');
      if (_exceptionData == 'read_external_storage_denied') {
        print('Permission was denied');
      } else if (_exceptionData == 'selection_canceled') {
        print('User cancelled operation');
      } 
      print('----------------------');
    });
  }

Changes:

• On error, underlying exception is disclosed while debugging (worth noting: FileSelectionCanceledError is still used, so no breakage in that regard)
• reason() when using something like onError() will return a more verbose reason
  • Most handled exceptions in _methodMap() will get assigned the value "selection_canceled" (as those occur when.. well.. the user cancels selection)
  • PlatformException gets its own value set as a value (i.e. read_external_storage_denied), as it can occur for multiple reasons (i.e. attempting to launch the file selector when already opened)
  • Unhandled exceptions will have their entire string returned (for developers to do the work themselves)

I will have to disclose that this has only been tested on Windows and Android. It's unknown what platforms such as Web, Linux, iOS and macOS would come back with. Although I do suspect that it means more adjustments to the changes I had made (especially when string splitting is involved).
I'm aware of try and catching not being used in the added code. This is done solely to help 'catch' any issues involving what was aforementioned while debugging. If needs be, it can be put into place meanwhile so that the fallback value is used (still being very useful).