This are handy utilities to automatically prepend context on error
return. For example in

	func myfunc(...) (..., err error) {
		defer xerr.Context(&err, "error context")
		...
		if ... {
			return ..., errors.New("an error")
		}
		return ..., nil
	}

while preserving nil error return on successful execution, myfunc will
return error with string "error context: an error" on failure case.

This is somtimes needed for checking programs output bit-to-bit where on
python side repr(x), `x` or %r is used for output.

Std fmt works ok unless you need to do text formatting in hot codepaths.
There fmt becomes inappropriate as it is slow and does allocations on
every formatting.

strconv also does not have append routines for every needed case, e.g.
there is no strconv.AppendRune, no strconv.AppendHex etc.

So xfmt

1. provides append routines for builtin types lacking in strconv

2. introduces xfmt.Stringer interface which types can implement to hook
   into general formatting via xfmt.Append()

3. provides xfmt.Buffer which is []byte with syntatic sugar for
   formatting in a way similar to printf: For example if in fmt speak
   you have

	s := fmt.Sprintf("hello %q %d %x", "world", 1, []byte("data"))

   xfmt analog would be

	buf := xfmt.Buffer{}
	buf .S("hello ") .Q("world") .C(' ') .D(1) .C(' ') .Xb([]byte("data"))
	s := buf.Bytes()

   and xfmt.Buffer can be reused several times via Buffer.Reset() .

The above xfmt.Buffer usage is more uglier than fmt.Printf but much less uglier
than direct strconv.Append* and friends calls, and works faster and without
allocations compared to fmt.Printf:

	BenchmarkXFmt/%c(0x41)-4                20000000                65.4 ns/op             1 B/op          1 allocs/op
	BenchmarkXFmt/.Cb(0x41)-4               200000000                5.96 ns/op            0 B/op          0 allocs/op
	BenchmarkXFmt/%c(-1)-4                  20000000                70.1 ns/op             3 B/op          1 allocs/op
	BenchmarkXFmt/.C(-1)-4                  100000000               12.9 ns/op             0 B/op          0 allocs/op
	BenchmarkXFmt/%c(66)-4                  20000000                65.8 ns/op             1 B/op          1 allocs/op
	BenchmarkXFmt/.C(66)-4                  100000000               12.7 ns/op             0 B/op          0 allocs/op
	BenchmarkXFmt/%c(1080)-4                20000000                67.2 ns/op             2 B/op          1 allocs/op
	BenchmarkXFmt/.C(1080)-4                100000000               12.8 ns/op             0 B/op          0 allocs/op
	BenchmarkXFmt/%c(8364)-4                20000000                69.4 ns/op             3 B/op          1 allocs/op
	BenchmarkXFmt/.C(8364)-4                100000000               13.8 ns/op             0 B/op          0 allocs/op
	BenchmarkXFmt/%c(65537)-4               20000000                70.5 ns/op             4 B/op          1 allocs/op
	BenchmarkXFmt/.C(65537)-4               100000000               14.3 ns/op             0 B/op          0 allocs/op
	BenchmarkXFmt/%s("hello")-4             20000000                72.3 ns/op             5 B/op          1 allocs/op
	BenchmarkXFmt/.S("hello")-4             200000000                9.40 ns/op            0 B/op          0 allocs/op
	...

- small addons over std bytes package: xbytes.ContainsByte
- (re)allocation routines for byte slices

So far only one of them: CeilPow2 to return min(y) >= x: y = 2^i - i.e.
next power of two >= x. This is handy to have in reallocation routines
to allocate buffers from 2^i classes.

Two implementations:

- fast for go19
- slower fallback for go18

As it was planned switch to using runtime.Frame instead of our
local imitation.

Add test to make sure we are not breaking anything.
Adjust users in exc.

To determine current function's file name, line number and runtime.Frame

Because in general case runtime.CallersFrames is more accurate than
runtime.FuncForPC - e.g. the latter does not correctly work with inlined
functions.

This causes the following changes on client side:

	myname.Func	-> my.FuncName
	myname.Pkg	-> my.PkgName

Reason for the change is that we are going to introduce my.File and
my.Line which would not fit into myname package naming.

We want to make sure that the code can be used by Free Software and Open
Source projects without a problem.

So change the license to be GPLv3+ with wide exception for all
open-source licenses which practically cover them all.

exc += XRun() - utility to run a function which returns regular error, and raise exception if error is not nil

This might be frequently needed in tests, possibly with some kind of
"apply" syntatic sugar.

Complements 486ede30 (exc += Runx() - utility to run a function and
translate caught exception to regular error)

Previously Error() was giving "0 errors", but "" seems to be a better
choice.

Anyway proper usage of Errorv is to call .Err() when handing result to
some where so this way empty-vector case becomes nil.

- various .Append*() are functions to add errors to error vector.
- .Err() returns error in canonical form accumulated in error vector -
  e.g. nil when error vector is empty.

Name for error vector: ev -> errv

This might be frequently needed when running a goroutine - to catch
errors at top level and then convey they to other places as regular
errors.

Fix this thinko in Addcallingcontext description.

In current Error.Error() only function names are printed but with actual
frames there in error context clients will be probably able to access
this information theirselves.

Because not only go.git wants to increase verbosity on `-v -v ...`.

Code taken from go.git ec80737bdf.

No many details since they can be all viewed e.g. with help of godoc.
Just a top-level pointer.

Move them here to go123 like in previous patches. Taken from git-backup
0be1f647.

[1] https://lab.nexedi.com/kirr/git-backup

Pristine import + package/copyright clauses. Taken from git-backup 3aedc246.

[1] https://lab.nexedi.com/kirr/git-backup

Export functions that client would use and adjust their names taking
into account that now there is a package prefix. So e.g.

	raise		-> exc.Raise
	errcatch	-> exc.Catch
	erronunwind	-> exc.Onunwind
	...

It is completely orthogonal to exception handling.

It is

	xruntime.Traceback()

Usage would be:

	myname.Func(),	and
	myname.Pkg()

This is pristine import. Files are taken as-is from git-backup 3ba6cf73.
Will adapt them to live in separate package in the next commit.

[1] https://lab.nexedi.com/kirr/git-backup

This will be a place to keep handy go bits shared across projects.