bug#39349: browse-url-of-dired-file should respect directory symlinks

[積丹尼 Dan Jacobson]

LI> Then...  I don't know what Dan is reporting here.  :-/

LI> I've now set up a proper test case, and I can't reproduce the bug, Dan.
LI> Could you explain more closely what you're seeing and what you're
LI> expecting to see?

$ ls -ogd /cf
lrwxrwxrwx 1 11 2016-12-24  /cf -> /mnt/usb/cf
$ ls -ogd /cf/updates
drwxr-xr-x 49 37888 07-30 19:00 /cf/updates
$ ls -ogd /cf/updates/0952053635.html
-rw------- 1 784 2017-12-15  /cf/updates/0952053635.html
$ chromium /cf/updates/0952053635.html        # Browses 
file:///mnt/usb/cf/updates/0952053635.html as seen in the URL bar
$ chromium file:///cf/updates/0952053635.html # Browses 
file:///cf/updates/0952053635.html as seen in the URL bar
$ w3m /cf/updates/0952053635.html             # Browses 
file:///cf/updates/0952053635.html as seen with the "=" command
$ w3m file:///cf/updates/0952053635.html      # Browses 
file:///cf/updates/0952053635.html as seen with the "=" command

(Firefox acts like chromium.)

$ emacs /cf/updates
then there do browse-url-of-dired-file on 0952053635.html

Well that calls chromium or emacs-w3m on
file:///mnt/usb/cf/updates/0952053635.html
as seen in chromium's URL bar, or emacs-w3m's "c" or "=" commands.

Anyways, I'm saying that the user doesn't want to be made forcibly aware
of the real URL. So browse-url-of-dired-file should probably put a
"file://" in front of what "0 w" (w runs the command 
dired-copy-filename-as-kill)
returns, when invoking the browser.

0 w (0 dired-copy-filename-as-kill) uses the symlink path reliably.