[Enhancement proposal]: Pass Permissions by `String` instead of `int`

### Please check the following before submitting a new issue.

- [X] I have searched the [existing issues](https://github.com/baseflow/flutter-permission-handler/issues).
- [X] I have carefully [read the documentation](https://github.com/baseflow/flutter-permission-handler/blob/main/permission_handler/README.md) and verified I have added the required platform specific configuration.

### Please select affected platform(s)

- [X] Android
- [X] iOS
- [X] Windows

### Proposal

Currently, communication of permissions over the method channel happens by sending integers. Every permission is associated with a unique integer. The proposal would be to send over unique strings instead.

Right now I'm thinking of a simple change, where we replace the `Permission` class with an enum. We can use the `name` property of enums to communicate over the method channel. Changing permissions to an enum is also proposed in #848, albeit for different reasons.

Current implementation:
```dart
/// Defines the permissions which can be checked and requested.
@immutable
class Permission {
const Permission._(this.value);

/// Creates a [Permission] using the supplied integer value.
factory Permission.byValue(int value) => values[value];

/// Integer representation of the [Permission].
final int value;

/// Android: Calendar
/// iOS: Calendar (Events)
static const calendar = Permission._(0);

...

/// Returns a list of all possible [PermissionGroup] values.
static const List values = [
calendar,
...
];

static const List _names = [
'calendar',
...
];

...
}
```

Proposed implementation:
```dart
/// Defines the permissions which can be checked and requested.
enum Permission {
calendar,
...
}
```

### Pitch

This refactor will greatly benefit contributors when adding new permission support to a subset of the supported native platforms.

Currently, when a permission is added to a platform, we urge contributors to add the permission identifier on every platform. This ensures that we keep the numbering in sync and do not end up with a mismatch. For example, Android defining permission with value `10` to be `calendar`, and iOS defining permission with value `10` to be `contacts`.
The problem with this approach is that it requires all packages to be updated and published to pub.dev, even the ones that are unaffected by the initial change.

By sending unique strings, as opposed to integers, we do not have to worry about keeping implementations in sync, as it is very unlikely for to different permissions to be identified with the same string.

Recently, we experienced described situation. A new BODY_SENSORS permission was added to Android, but also the iOS and Windows packages had to be updated. See #1074.