Go packaging

[stefanotorresi]

This PR introduces a more proper separation of the various parts of the project using Go packages.
Every collector now has a dedicated sub-package inside the collector package, and common generic code is stored in dedicated internal packages. All of this was done according to various Go best practices.

The only code in the main package is the one that creates the binary.

This is propedeutic to further development where some structs are very likely to eventually occur into name clashes (e.g. Resource, Device, Node are all entities that may be present in different collectors), so they needed to be namespaced in different packages.

[MalloZup]

looks like a really small package this one :/

[MalloZup]

ok thx. the pkg refactor should had been done soon or later (better in the middle as to sooner or later).

looks good. only the clock package could we put perhaps somewhere if possible (but not utils a like things). But I'm fine also with this

[stefanotorresi]

I'm glad you approve @MalloZup, I spent a non-trivial amount of time on this, to find a naming that works, which is hard as usual!

By the way, utils and other generic package names are actually very discouraged by Go best practices, and rightfully so: generic names obfuscate their content and do not communicate intent, while a name like clock allows to immediately spot what it's about, and the fact that it's small is only determined by its limited scope.

Besides, I think there is nothing wrong with a very small package, OTOH a miscellaneous package will eventually grow and become confusing at some point!

[MalloZup]

@stefanotorresi yeah I know that utils is weird man :grin. I was tryint to optimize the optimized. I think is ok to have small things 😁 . Unless they are not milions of it , but we are ok