Add `optError`, `optValue`, to convert back and forth between Opt and Result
These conversions end up being more common than others since "trivial" success/fail-style API often use Opt while combining such API into combined operations tends to prefer richer error reporting.
This, together with bitops2 and endians2, forms the core primitive
offering for working with integers as the computer sees them.
The focus of intops is to expose a number of common integer operations
typically used to build more complex abstractions such as bigints,
mp-ints etc while having access to the best performance the compiler and
cpu can offer.
There is more to do here, but this provides an outline of what this
module could look like.
Obviously, there are no exceptions or defects around - the point of
these utilities is to stay as close as possible to bare metal. They
could be used to implement such features however (similar to how
`system/integerops` works).
These two helpers complete `valueOr` and `errorOr` to cover `void` cases
where no value should be returned or `Result[void, E]` /
`Result[T, void]` is being used - they can be used for a convient
early-return style in side-effectful proc:s:
```nim
v.update().isOkOr:
echo "update failed: ", error
```
* Add API call from a (slight) future 1.6 branch with when guards to
deactivate as per claim here
https://github.com/status-im/nim-codex/pull/346#issuecomment-1432073926
that this (or something very near it) is where it belongs.
* I also cannot find any `shims/parse` import. See discussion here:
https://github.com/status-im/nim-stew/pull/173
So, rename module to match upstream Nim stdlib.
If anyone complains, re-create `parse.nim` that simply does import
& re-export parseutils & self-deprecates.
The lock file breaks devel testing - CI updates are needed as well as a
strategy for handling "nim important packages" builds (which build with
a version of Nim different from that in the lock file)
