possible fix for when user submission file is behind a symlink or juncti...

...on

This fixes (for me at least) the following (related) problems: https://github.com/rvagg/learnyounode/issues/108 and https://github.com/nodeschool/discussions/issues/415.

I can add to the discussion that the original problem occurs when the user submission file is referenced via a junction on a Windows machine, but also when the user submission file is referenced via a symlink on both OSX  and my CentOS linux box. This update fixes the issue on all 3 platforms. I also verified that 'common' operation, where the submission file is directly referenced (no symlink  or junction) continues to work on all 3 platforms.

As others have noted, the `stack[0].getFileName()` call in `learnyounode/exercises/my_first_io/wrap.js` (and possibly other locations) returns a fully resolved path using the actual dereferenced path, whereas `cts.mainProgram` which originally is set with:
```javascript
mainProgram   = ctx.mainProgram = path.resolve(process.cwd(), myargs[2])
```
in `workshopper-wrappedexec/exec-wrap.js` still contains the symbolic link reference value in the path. Therefore, the comparison on line #29 of `learnyounode/exercises/my_first_io/wrap.js` never triggers and so later on in the `Object.keys(exercise.wrapData.fsCalls).forEach()` loop  on line #56 of `learnyounode/exercises/my_first_io/exercise.js` it never actually enters the loop because `fsCalls` is empty, and so the `usedSync` flag remains false and you get a failure.

The one thing I'm not 100% sure of is where else `ctx.mainProgram` may be used and if it's completely safe to change it from the non-dereferenced value to the fully dereferenced value (via `fs.realpath()`). I did search around a lot and it seems to be a safe change.