Fix/windows dev fixes

[tdn]

Added .gitattributes and .editorconfig to make life easier for Windows-based devs.

Also added an option to boot.sh to enable --legacy-watch instead of --watch for nodemon, since code reloading doesn't work when you mount your code from a Windows host machine.

It turns out nodemon --watch won't work if your code resides on Windows, but --legacy-watch should.
It's less efficient and more error-prone than --watch, but at least it works.

Set the DEV_OS environment variable to windows so boot.sh will use --legacy-watch, and you should have live-reload.

Please verify that this doesn't interfere with Linux deployments/setups before merging

[madnificent]

Thank you for this pull request. It seems to solve two parts to improve the experience for windows users.

These comments are a conversation starter. If you agree, we can probably also update the PR.

I don't think we can sufficiently support windows at this time. This addition is sane, but we notice the stack is substantially slower on Windows and still consider it to be a handicap for the developers in question. This improvement is a first step from our end but important steps should be taken on Microsoft's end to get this into a sanely used state. As such, I consider this PR to be a welcome improvement, but it's not my intention to fully support windows at this time and it's not something we can control or steer as Microsoft will probably only read messages like this in an automated manner ;-)

With that in mind, such improvements from your end are great for removing our blind spots.

Legacy nodemon

Monitoring now happens through --legacy-watch. This looks like a sane addition. Thank you.

Looking at this online, other users claim this isn't an issue anymore [1],[2]. Can you verify the issue persists for you?

Could we perhaps always fall back to --legacy-watch for environments that don't support file watching, rather than making users set a new environment variable?

Editor configuration

The editor configuration added to this repository would only help for users developing the template itself, not for users developing in the template. Is this the intention? Do we intend to support users using this template too? In such case we should have a look at the mu-cli [3] as well.

Binary files

We're now adding a somewhat random set of binary files to not be changed through line endings. A non-exhaustive list which is not used in the project itself adds confusion. Perhaps it's better to add one example and override if/when/should binary files be included at some point?

---

[1] https://stackoverflow.com/questions/39239686/nodemon-doesnt-restart-in-windows-docker-environment
[2] https://www.docker.com/blog/new-filesharing-implementation-in-docker-desktop-windows/
[3] https://github.com/mu-semtech/mu-cli