_User class email field protection should be modifiable

Is your feature request related to a problem? Please describe.
As discussed in a Parse Community forum thread, the default behavior of the _User class email field is to protect it and only expose it via useMasterKey. This is a reasonable default setting.

However, developers who understand the risks involved may have a reasonable need to access the email field in a find query, but are currently unable to do so. The email field does not respond to a removal from protectedFields. A developer can get around this limitation via adding their own email-related field, but doing so feels hacky. Parse simply does not allow a developer to change the protected behavior of the default email field even though a method to do so is built into Parse.

Parse's default setting for the email field is good. Unless the risks are understood and the default behavior is intentionally overridden, it's reasonable to disallow exposing the email field.

Describe the solution you'd like
If, however, a developer understands the risks and wishes to expose the email field in queries, s/he should be allowed to do so. The email field should respond to protectedFields changes in the same way that other fields do.

Describe alternatives you've considered
Create a clone of the email field and expose its contents in User class queries. This is not an elegant solution.

Additional context
Though I believe allowing developers to change the email field's behavior would be good, it should be accompanied by the addition of wording in the docs that both describes how to use the protected fields feature, and a caution against making a change to the email field's behavior unless the risks are understood. I believe that there is currently no verbiage in the docs about these things.

Start by tracing how protectedFields is applied to the _User class email field, then review the existing protected-fields documentation. Confirm the expected behavior with tests for find queries and protected-field changes, and update the documentation with usage guidance and a warning about exposing email addresses.