Define .msh as a binary file (for git purposes)

[Sbozzolo]

My #449 PR adds 360,888 lines. Of course, this does not really reflect the change in this PR. The reason for so many lines is that it includes msh files.

msh files are text files so git handles them as source code. However, we never really want to look at diff of msh files.

I have locally this change to my gitattributes so that I don't accidentally print a 100k loc git diff, but I think that this might be useful more broadly.

This change tells Git to treat all files with the .msh extension as binary files. This means:

1. No diff display: Git won't show textual diffs for these files
2. No merge attempts: Git won't try to merge conflicts in these files
3. Obscure, but did you know that in some cases git modifies line endings (depending on the operating system and git settings)? Setting msh files are binary means that git won't attempt line ending conversions

[cameronrutherford]

However, we never really want to look at diff of msh files.

So long as this assumption holds true, I think these changes are fine.

Is it still easy to inspect the diff if I wanted to?

[Sbozzolo]

So long as this assumption holds true, I think these changes are fine.

If the number of total element in a mesh changes, every line of the file will be different, and pretty much any change in the mesh generation leads to a different number of elements.

Is it still easy to inspect the diff if I wanted to?

Yes, you can git diff --text if you need to.

[Sbozzolo]

Note that an alternative is to directly output binary mesh files. That would reduce storage requirement for meshes (and this PR won't be needed)

[hughcars]

I think this is a good idea, and should probably be accompanied by converting the meshes to binary format. This would however requires rerunning all the mesh generation files, which will change the meshes a little bit. So in the spheres example, this means changing mesh.jl with

    gmsh.option.setNumber("Mesh.Algorithm", 6)
    gmsh.option.setNumber("Mesh.Algorithm3D", 1)

as 3d algorithm 1 is more reproducible than HXT, these meshes are generally all so small that using the default of 1 is fine. Next gmsh.option.setNumber("Mesh.Binary", 1), then the case would be re-run, and the reference data from postpro copied to test/examples/ref/spheres, and finally the spheres.md updated for each.

The spheres mesh file reduced by about a factor of 2 in size going to binary, and all the derived quantities in the csv files barely changed (3rd s.f mostly). This would be a reasonably large amount of manual work to change them all, but I think probably worth it in advance of your other PR.