check-eof-newline: handle filenames with spaces
check-eof-newline: handle filenames with spaces

check-eof-newline.sh doesn't properly handle filenames with spaces,
instead treating them as multiple files instead.

For example, we can create a file whose name has spaces, e.g.
'filename with spaces.txt'. Ensure that the file has some content inside
so that Git will detect it as a text file so it will be checked by
check-eof-newline.sh:

    echo 'content' >'filename with spaces.txt'

Then use git-add to track the file:

    git add 'filename with spaces.txt'

Then run check-eof-newline.sh:

    ./config/travis/check-eof-newline.sh

check-eof-newline.sh will then spew out the following errors:

    tail: cannot open './filename' for reading: No such file or directory
    tail: cannot open './with' for reading: No such file or directory
    tail: cannot open './spaces.txt' for reading: No such file or directory

While this won't cause check-eof-newline.sh to error out (it will simply
ignore those bogus filenames), it is still incorrect behavior since the
file 'filename with spaces.txt' doesn't actually get checked by the
script.

This happens because when check-eof-newline.sh is reading the list of
filenames from git-grep, the IFS variable is not set, and thus the shell
will split the lines of filenames on <space>, <tab> and <newline>,
resulting in filenames with spaces getting split into multiple
filenames.

Fix this by explicitly setting the IFS variable to <newline> before
reading from git-grep, so that the lines of filenames will only be split
on newline boundaries -- filenames with spaces will be preserved.

See http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03
for more info on the IFS variable.

damithc/addressbook-level4,damithc/addressbook-level4,se-edu/addressbook-level3,damithc/addressbook-level4