RFE: non-repeatable options should warn if repeated?

[smcv]

Some bwrap options cannot usefully be repeated: they overwrite the same variable repeatedly.

For --seccomp see #453.

Options like --unshare-uts and --clearenv are obviously idempotent, so it makes sense for them to succeed silently if repeated.

For --cap-add and --cap-drop the meaning is specifically documented, so that seems fine.

--userns, --userns2, --pidns, --uid, --gid, --hostname, --exec-label, --file-label would make no sense to repeat (the overwriting semantic is the only thing that could possibly work), so they should maybe warn if repeated.

--sync-fd, --block-fd, --userns-block-fd, --info-fd could reasonably be assumed to be repeatable, but actually they're not. As with #453, I think repeating the non-repeatable option should print a warning. Or repeating these options could be a fatal error, but that could conceivably be a backwards-compat break, so perhaps best not.

It might also be nice to make the options like --sync-fd repeatable (keep more than one fd open while the sandbox is running, etc.). As with #453, I think the safest way to do that would be a new option like --add-sync-fd, etc. rather than changing the semantics of the existing options. However, I think it's only worth doing that if duplicating the action is genuinely useful.

[smcv]

You might also reasonably expect that --chdir /foo --chdir ../bar would have the effect of cd'ing to /foo/../bar, i.e. /bar, but in fact it does not; so I think that should warn too.