Add a file crawler in background as backup for FileSystemWatcher

[mkromberg]

FileSystemWatcher mechanisms are fundamentally unreliable on all platforms. A mechanism needs to be added to periodically scan the file system for events which have been lost.

[nicolas-dyalog]

related to #120

[nicolas-dyalog]

Requires fixes to :

• Mantis 18633
• Mantis 18631

[bernecky]

I assume that Morten's assertion of 2019-07-30 is correct. Given that, here is a possible workaround, based
on (MY) user habits during development and debugging in a unix/linux environment.
I assume that )ed and friends work correctly, and update any linked host system files when the editor exits. Hence, we need concern ourselves only with someone tinkering a file folder from outside APL.

I try to use one text editor (vi/vim) for all my work, as it facilitates my typing habits, muscle memory, etc.
So, my workflow is, with APL being the APL session, and LINK being an xterm or other command prompt doodad:

  APL:  foo 42
domain error foo[2]

  LINK:  vi foo  
    [fix the error]

  APL: )reset maybe 
      foo 42
1 2 3

Morten's problem arises at the above LINK->APL window change, by me and my mouse.

This suggests that, if APL (RIDE?) can detect the arrival of the cursor in the APL window, or
even a change in focus to the APL window, that is (for me) an adequate trigger for looking at
file timestamps in LINK. Just once.

I think that is sufficient unto my day. Am I missing something? If so, let's look elsewhere:

I have no idea what ]link behavior is defined, or desired, when a host-side-edited function changes,
but the function is on the execution stack. If I recall correctly, the function on the stack is decoupled
from the one in the workspace, so nothing appears to change (for the APL session) until the stack is empty of that
function. Hence, function exit could trigger the LINK timestamp search. Not a good idea from a performance
standpoint.

However, return to immediate execution could trigger a LINK timestamp search, with much less overhead.

I am not enthused with an egg-timer approach, in which the interpreter would "periodically" do the LINK
timestamp check. If done too frequently, then APL is bashing disk/network every second or so.
If done infrequently, a function that I Know Has Changed does not appear in the APL namespace
when I want.

I think I want a focus-change-detection-based approach.