If it's your project, you should make sure it actually works. Whilst you can't check that some proposed change works (and doesn't introduce anything malicious), you should only pull it if you know the author well already and trust them. That's the only thing I'd consider “ethically mandatory” here. If the PR is a risk factor, don't pull it.
That said, I find it generally rather annoying if project maintainers bog their code down with old standards. So first of all I'd just give it a shot: pull that change, but to a separate branch of your repository, not to master. Then try if you can actually work on that branch with your old version of VS; perhaps this actually works, I don't know anything about .sln. If it does work, then just go ahead.
If it does not work, it might still be sensible to try it: check the project out on a machine that has a suitable version installed (perhaps using a CI service like Travis). If you can confirm that the change is valid but you just can't personally work with it anymore, than my advice would be to pull it in the master branch, but do all your own work on a seperate branch legacy/VS2013 that has an extra commit reverting the .sln file to a version you can work with. After every change, you'd than rebase that commit back on top and reset your master branch to incorporate the relevant changes but not the legacy revert. Goes something like this:
$ git checkout master
$ git pull contributor/proposedChanges
$ git log
... # Look for the SHA1 of the commit that changes the .sln file
... # Let's pretend it's 1234abc
$ git checkout -b legacy/VS2013 # make new branch and switch to it
$ git revert 1234abc
At this point you should be able to normally work on your legacy branch using VS2013, while the Github repo is officially at the new standard. If you now make some changes on your branch
$ git commit -m $'Some new change of my own'
$ git commit -m $'Some other new change'
then you first need to rebase that work so update the master branch accordingly.
$ git rebase -i HEAD~3
This will give you an editor view like
pick cba4321 Revert update to VS2015
pick 8820444 Some new change of my own
pick ffe5519 Some other new change
Change the order to
pick 8820444 Some new change of my own
pick ffe5519 Some other new change
pick cba4321 Revert update to VS2015
and save&quit the editor.
After that, git log should also display the new order, i.e. the revert comes last.
To publish your changes without the revert, you now just update the master branch accordingly:
$ git checkout master
$ git merge legacy/VS2013^ # penultimate commit on that branch
and then update the online repo
$ git push origin
...and switch back to your own branch for further work
$ git checkout legacy/VS2013
As a broader thing... if updating is such a problem you might want to consider to switch to an entirely different development environment in the future, preferrably something free like Mono.
