I think we need an example of, if the tasks return before the context
cancelled due to timeout, it should success

Co-authored-by: Camden Cheek <[email protected]>

Fixes #98

Fixes #103. See inline comments for rationale.

For "unlimited" pools, in the original code:

```go
p.handle.Go(p.worker)
p.tasks <- f
```

If in between the call to `handle.Go` and sending the task to the
worker, another goroutine would call `pool.Go`, that task would "hijack"
the newly created worker, causing the original send to block. This is
undesirable behavior if the pool is unlimited.

The solution was to add an `initialFunc` to the worker, which will be
executed before the worker starts waiting for new tasks. This ensures
that a worker will first complete the task it was supposed to, then
complete others.

In #104, a "FailFast" option is
likely going to be added to iterators that, on error, stops running
additional tasks and returns the error that caused the first failure.

"FailFast" seems is a pretty standard description for this behavior, and
combining two common options into a single option with a more
discoverable name seems like a nice thing to do before 1.0.

Clarifies questions in #101

We use the new error facilities when built with go 1.20, so this TODO no
longer applies.

The main reason for this PR was to make the examples in documentation
copy-pasteable, but there are some additional benefits too.

For example, the pool example before this change:

```go
p := New().WithMaxGoroutines(3)
for i := 0; i < 5; i++ {
	p.Go(func() {
		fmt.Println("conc")
	})
}
p.Wait()
```

and after:

```go
p := pool.New().WithMaxGoroutines(3) // has package name
for i := 0; i < 5; i++ {
	p.Go(func() {
		fmt.Println("conc")
	})
}
p.Wait()
```

Currently, if `nil` is returned as a stream callback, it will cause a
panic because we try to call a `nil` func. This makes it valid to return
a `nil` callback from the stream job, which just does nothing on
callback.

The `//go:build` directive was added in go 1.18, but this module
requires at least go 1.19, so the old version of these build directives
is unnecessary.

This fixes `MapErr` so that it does not create recursive `joinError`s.
By repeatedly calling `errors.Join(`, we create a nested set of
`joinError`s rather than a single, flat `joinError`. Then, when
`Error()` is called, it allocates a new string for each nested error
because `joinError` calls `Error()` recursively on each of its children.

Instead, this PR updates `MapErr` to just collect a slice of errors and
return the flat joined error.

This makes the order of results in a `Result.*Pool` deterministic so
that the order of the result slice corresponds with the order of tasks
submitted. As an example of why this would be useful, it makes it easy
to rewrite `iter.Map` in terms of `ResultPool`. Additionally, it's a
generally nice and intuitive property to be able to match the index of
the result slice with the index of the input slice.

This updates the pool types that collect results and errors to reset on
`Wait` so they are reusable once waited on. Previously, if a pool was
reused, the returned values of `Wait()` would contain the aggregated set
of all previous uses. This wasn't explicitly a guarantee of the library
before, but it does make it operate more like `sync.WaitGroup` and it's
easy to do, so I think it's a positive change.

This removes the dependency on `go.uber.org/multierror` in favor of
the multierror functionality included in go 1.20.

This:
- Adds a Makefile with `make test` and `make lint` and `make bench`
- Adds a new workflow for `main` that runs benchmarks and saves them
- Adds a new workflow for PRs that runs benchmarks and compares against
`main`. When a benchmark regression occurs, it should fail the workflow