"secret" keyword

[handrews]

Originally suggested by @chrisdostert in json-schema-org/json-schema-spec#249

Currently, it is more likely that a writeOnly keyword will go in the main spec, but a presentation-oriented secret keyword would also be of use on top of that. It would cover obscuring the data in form input, logs, etc.

[handrews]

Reopening as the old spec repository issue had several things in it including both writeOnly and secret and was closed when the writeOnly keyword was added. secret is still a useful proposal, corresponding roughly to OpenAPI's "format": "password", except without the problem of having anything to do with format.

[underdarknl]

OpenKAT has chosen to implement a secret keyword, similar to the required keyword for the following usecase:
Some fields are secrets and should be handles as such based on the user interacting with that data. for us, Users do not have rights to see secret fields. Other users with more rights (installation admins, redteamers) do have a right to see the secrets, and if needed change them.
A WriteOnly property does not quit cover the usecase, as that would imply no-one could re-use an already present secret easily when making partial changes to the data covered by the schema.