swap, uint256: move Uint256 implementation to new swarm/uint256 package

[mortelli]

(this builds on #2063 and adds to it)

This PR:

• adds a new swarm/uint256 package
• moves the Uint256 type from swap package to uint256 package
• adds the etypes alias to go-ethereum/core/types package when it coexists with the swap/types package in a single file discarded change

Since this is the first time I am adding a new package to Swarm, I have opted to do it through an internal PR to have an instance for name changes.

Discussion points:

• alias choice for go-ethereum/core/types discarded change
• to reduce verbosity, types could have a short alias, such as t. For now, I have opted not to do this for reasons of code clarity, at the cost of wordiness. discarded change
• the idea of renaming Uint256 (e.g. to U256) has also been thrown around in the past. This would be a good time to change this, if desired.
  • keep in mind this would also shorten some arguably uncomfortable function names; e.g. Uint64ToUint256 to something like U64ToU256 (although we expect to retire this particular function in the short future)

[janos]

We should avoid generalised packages. I think that Uint256 can have its own package with a very small scope, not a general purpose types package as per suggestion from https://github.com/golang/go/wiki/CodeReviewComments#package-names.

[mortelli]

We should avoid generalised packages. I think that Uint256 can have its own package with a very small scope, not a general purpose types package as per suggestion from https://github.com/golang/go/wiki/CodeReviewComments#package-names.

alright, this makes sense. but if i name it something like swap/uint256, then i would like to change the function names to avoid redundancy, like so:

types.NewUint256 → uint256.New
types.Uint64ToUint256 → uint256.FromUint64

(and so on)

although the struct itself would be uint256.Uint256, which isn't ideal.

thoughts?

[janos]

I would not mind so much uint256.Uint256 even it is too verbose. There are cases where the only type in a package is named as the package is. One idea that I have in mind is uint256.I like testing.T, but I am not sure if that is better.

[mortelli]

I would not mind so much uint256.Uint256 even it is too verbose. There are cases where the only type in a package is named as the package is. One idea that I have in mind is uint256.I like testing.T, but I am not sure if that is better.

alright. then i'm going to merge this to #2063 and if we want to talk about names further, the discussion can take place there.