bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> In the absence of a file-name-handler, it should just defer to write-region.
> I'm confused: I thought we were talking about features implemented via
> file-name handlers.  jka-compr is, for example.

Here's how I hope for it to work:

write-region-literally checks file-name-handler, finds HANDLER and delegates
to it, if HANDLER has a special handler for it (e.g. jka), then that
handler will presumably end up calling write-region, but if it doesn't,
then it rebinds inhibit-file-name-operation’ and
‘inhibit-file-name-handlers’ and calls write-region-literally again
which this time won't find this file-name-handler.

> For the present use case, sure.  But we are discussing a more general
> solution, right?  The question is, will all of them want to disable
> those conversions?

I'm suggesting to add write-region-literally and the "inverse" or
insert-file-contents-literally.  Just like
it is the case for insert-file-contents(-literally), there are in theory
middle points, but in practice those can be reached by manually
performing the extra encoding/decoding that the `-literally` version
doesn't do but that we'd need in this case.

IOW since we don't have any
`insert-file-contents-literally-but-please-do-the-coding-system-decoding`,
I don't think we want a `write-region-literally-but-not-quite`.


        Stefan