Refactor volatile operations (try 2)

[aykevl]

This replaces #325 with a better to use API.

I tested examples/blinky1 and examples/blinky2 on an Arduino Uno, and tested examples/blinky1 on a digispark. They all still work, but code size is significantly increased. I'll improve this PR to avoid that.

[aykevl]

This refactor is also part of #285. Removing //go: volatile will make that possible.

[deadprogram]

My first impression is really positive. The code looks a lot clearer and cleaner this way than using all the operators.

[aykevl]

I fixed it (mostly) with //go:inline hints. I'm much happier with those because 1) they are set on a function definition and not on a declaration (thus are only relevant to the package itself, the information does not have to travel package boundaries) and 2) it is only a hint, it does not require anything from the compiler. In fact, gc will ignore it (see golang/go#21536). The //go:volatile hack is basically an extension of the type system, having all sorts of weird edge cases like #151.

Unfortunately, code size does change. For examples/blinky1 and examples/adc it gets slightly smaller, and for examples/echo it gets a bit bigger. Behavior is unchanged in my tests. I'm slightly worried it might badly affect the other targets but if it does, we can look for alternatives. I prefer this API much more than the current/old compiler hints/hacks so we should make the compiler smart enough to optimize it away.

[deadprogram]

OK, so seems like we will need the equivilent PR for the various ARM-based MCUs. There are a lot more implementations to port, I am happy to help with that once you have the core code. We should merge any outstanding machine package commits first, if possible.

Also, just wondering if perhaps the AVR SPI implementation that @torntrousers was working on might be ready to merge before this PR lands? Otherwise there will be some changes he will need to make first.

I looked at the code size differences a little, and they were very small, as in 16-64 bytes total. That is easily worth the benefits, IMO.

Anyhow, we should figure out how to proceed, and do it as soon as possible. I really want this API now that I have seen it.

[aykevl]

So which one should go in first? I see there is a merge conflict that's trivial to resolve (EDIT: fixed), but other than that I would prefer to merge this one first as long as there is no PR from @torntrousers (unless he intends to make one soon). The longer this one waits, the more maintenance it will require.

[torntrousers]

Please don't wait for me. Been held up by life and all the i2c things.

[deadprogram]

Thanks for the update @torntrousers when you do get around to it, the changes should not be very substantial.

OK I will merge this PR so we can keep going.

The only ARM-based PR still outstanding is the one from @Munsio #333 which would appear to be nearly complete. Seems like would be very good to merge that one before starting the ARM migration, probably.