CLI's -D fails when the argument is not a regular file

[JustAnotherArchivist]

Describe the bug
The -D option of the CLI appears to expect a regular file and fails when Bash's process substitution feature is used.

To Reproduce
Steps to reproduce the behavior:

1. wget https://github.com/facebook/zstd/raw/c2c6a4ab40fcc327e79d5364f9c2ab1e41e6a7f8/tests/dict-files/zero-weight-dict (or another valid dict)
2. Bash: echo test | zstd -D <(cat zero-weight-dict) >/dev/null
3. Get a confusing error zstd: error 32 : Dictionary file /dev/fd/63 is too large (> 33554432 bytes) when the dict is actually just 153 bytes.

Expected behavior
I would expect zstd to be able to read the dict from process substitution, FIFOs, and really anything compatible with open(2) and read(2).

Desktop (please complete the following information):

• OS: Debian oldstable and sid
• Version: 1.3.8+dfsg-3, 1.4.8+dfsg-3 on amd64 (binary packages from Debian, not compiled from source by myself)

Additional context
A real-world example is fetching a dictionary with curl and passing it directly to zstd, such that a pipeline like input-command | zstd -D <(curl -s https://example.org/api/get-current-dictionary) | upload is possible without writing anything to disk.

Another potential use case (which may go beyond this issue) would be to read the dict from stdin, e.g. dict-command | zstd -D - file. This would however be sort of equivalent to zstd -D <(dict-command) file with Bash.

[terrelln]

Bug:

• The error message is very unclear. It should specify that we don't work on regular files.

Feature request:

• Allow non-regular files for dictionaries.

[15596858998]

I think this is a problem similar to the problem of ‘#2873’, both of which are not clear about the interpretation of the error message of the unconventional dictionary. I think we can solve these two problems together.