New build system migration (issue #298 + 2 more improvements)

[Artemkth]

I have done several changes to original repo since I have forked, the most major of which is move to the new go 'module' system. which allows building the Mumax3. Using old legacy arrangements for whatever reason selects wrong tag in git repo(v3.9.3), and produces no executables (highlighted in issues section #298).

Implementing proper build system is trivial for the project as there is no significant external dependencies, and just involves appending v3 to all the mumax3 imported modules per the new convention. And it also allows easier forking, as building is now possible outside of $GOPATH. Check out my personal fork repo readme to how it is done.

I also have added few more features of my own over the years, I didn't knew how to split the pull request so please consider those as well:

1. New feature I added the ability to use custom geometry from external geometry files with function InitGeomFromOVF which takes an external file name as an argument. It initialises both the mesh parameters, as well as sets the internal geometry to be the one from the external file. This allows to bake profiles externally in, for example, Wolfram Mathematica or Python. Example simulation, Permalloy pig head, r~1um. The code for baking profiles I will release later. Geometry feature I extensively tested over last year, and haven't found any more bugs, yet, than I fixed in this PR.
2. Fixed OVF backend to follow the OVF standard specification more closely by allowing for both the whole line, and in-line comments. I've done verification with OOMMF checking that it accepts the comments. Mumax3 in main repo will crash when parsing a comment.

This version compiles for me, although, some minor changes to your CI scripts might be needed. Self tests run well, except the convergence test having a delta ~2e-5 higher than 1e-5 target.

[JonathanMaes]

Thank you for your contribution! The two improvements have been merged in dc06ce3. The function InitGeomFromOVF was changed to an extension (it is now called ext_InitGeomFromOVF) because its functionality is somewhat more complex than normal functions: it does not only load a shape, but also changes the grid size. The VoxelShape is also no longer exposed to the user, because arrays are not supported in .mx3 input scripts. This may change in the future.

This allows loading arbitrary OVF geometries, as in the example below.

The change to a Go module was not yet merged. What is the benefit of putting /v3 in every import statement? I have created a go.mod file for the new mumax3.11 release, which compiles fine without adding /v3.