FIX properly extract millis from the nsec part of timespec

[zuzkins]

There is currently a problem with the function bindings_get_date, in that it does not compute the ms part of the timestamp correctly.
The ns part of timespec should be divided by 1 000 000 rather than 1 000 as it is the case right now.

This problem manifests itself when implementing utimens function:

I have debug on when mounting my FS through OSX FUSE and when I touch a file this is the logged output:

utimens /f.txt 1502873454.867636000 1502873454.867636000

But when I log the arguments my implementation is given:

utimens (/f.txt, Wed Aug 16 2017 11:05:21 GMT+0200 (CEST), Wed Aug 16 2017 11:05:21 GMT+0200 (CEST))

Those are few minutes off (they are shifted in to the future). Correct timestamp is new Date(1502873454.867636000 * 1000) => Wed Aug 16 2017 10:50:54 GMT+0200 (CEST). Right now the millisecond part is added together with seconds and nanoseconds are used instead of millis.

This pull request fixes mentioned problem. I have no idea how to test this other than manually:

OSX FUSE log:

utimens /f.txt 1502873614.070006000 1502873614.070006000

After fixing it locally, my app logs:

utimens (/f.txt, Wed Aug 16 2017 10:53:34 GMT+0200 (CEST), Wed Aug 16 2017 10:53:34 GMT+0200 (CEST))

Which is what is expected: new Date(1502873614.070006000 * 1000) => Wed Aug 16 2017 10:53:34 GMT+0200 (CEST)

I have also looked at the function bindings_set_date, but it seems to me, that it is implemented correctly.

Thank you for your effort you put into fuse-bindings!

[sam0x17]

this explains the behavior I was witnessing a few months ago -- good catch!

[sam0x17]

@mafintosh this looks ready to merge