Make the :doc command work even if lf is not in the PATH, add lf environment variable

[ilyagr]

This makes lf export a new environment variable named lf with the path to the lf binary. So, scripts can use $lf instead of lf and work even in lf is not in the path.

The :doc command now executes $lf -doc (or %lf% -doc on Windows) instead of lf -doc. I'd appreciate it if somebody could double-check that this works on Windows.

If Go fails to find a path to the lf binary, $lf is set to the string lf so that it still works if lf is in the PATH. (Though, from looking at the source briefly, Go might already look in the path if it couldn't find the binary normally)

Before this change, :doc did not work if lf is not in the PATH. This is likely to be a problem for new users who are trying out lf and need docs the most.

Moreover, if a developer makes some changes to the docs and runs lf with go run ., :doc would previously return the docs for the version of lf in the PATH (if any) instead of what is expected.

---

Another motivation for this is to make adding command-line options like lf -buffers (see #1152 (comment)) or lf -marks, if we decide it's a good idea in the future, work regardless of whether lf is in the PATH.

[ilyagr]

I updated the PR to work if path to lf contains spaces. Again, I tested it for linux, but testing for Windows is TODO.

Turns out Windows has "evaluation" version one can run for free in a VM, so maybe I'll try that.

Update: Tried it on Windows. It doesn't seem to work with spaces in the directory. "%lf%" -doc works in cmd.exe, but !"%lf%" -doc doesn't work from lf. Weird.

I changed the Windows command back to %lf% -doc for now.

[gokcehan]

@ilyagr Looks good, thanks for the patch.

On a related note, I think we simply used os.Args[0] instead of os.Executable() for a similar purpose in startServer in main.go though I don't remember if there was a reason for using one over the other one.

[joelim-work]

On a related note, I think we simply used os.Args[0] instead of os.Executable() for a similar purpose in startServer in main.go though I don't remember if there was a reason for using one over the other one.

BTW, when I was working on #1309, I have found that os.Args[0] and os.Executable() can have different results on Windows, and possibly the root cause of #1097 is because the server fails to start properly if the lf path is wrong.

Update: I have found that for Windows, if lf isn't in PATH, you have to use .\lf and not lf, otherwise the server won't start properly.