Cannot exclude read-only paths from dpkg, as they still cause dpkg to fail

[Impact]

In certain very specific cases, certain directories on the filesystem can be read-only. As-is, this is problematic for dpkg in case some package wants to install files there - which is fine and expected. But when this situation is 'intentional', one might want to use --path-exclude for the selected paths. Currently, dpkg will *still* fail in such cases.

The reason is that dpkg, before starting work on the package, checks for any dpkg interrupted transactions. It does that by performing a rename() on the dpkg tmp files on the selected path, and if there is none (by checking errno for ENOENT and ENOTDIR), it continues the operation. But in cases where the file-system is read only, the returned errno is EROFS, which is not handled and treated as if the file is there but unable to restore it.

It feels like a valid case though - if the filesystem if readonly, we should not consider *this* as an error case. Without path-excludes, dpkg will fail at a different moment anyway. While if someone has a working setup where this path indeed should be read-only but excluded, we should let dpkg continue.

[Test Case]

Ideally, creating a setup where some directory (for instance, /lib/firmware) is read-only, and trying to install a package like alsa-topology-conf. The package installation should succeed without any files installed into /lib/firmware.

[Regression Potential]

As this is a change in dpkg, there's quite a lot that might go wrong. However, the change is rather limited. Problems can appear in handling of interrupted transactions, or by breaking package installation in overall.