Make goleak options more flexible to adapt to users' variety scenarios

Signed-off-by: Kante Yin <kerthcet@gmail.com>

fix  #93

---------

Signed-off-by: Kante Yin <kerthcet@gmail.com>
Co-authored-by: Sung Yoon Whang <sungyoonwhang@gmail.com>
Co-authored-by: Abhinav Gupta <mail@abhinavg.net>

Set only read permission on CI workflows since they don't need write
access.

When Fuzz testing, if the `-fuzz` flag is used then the fuzzing engine
is used to generate test cases out of the seed corpus, this causes
`testing.runFuzzTests` to be blocked until a failing input is found or
there is a signal to stop generating.
On the other hand `testing.runFuzzTests` is called even without the use
of the `-fuzz` flag, executes the input testing with all the elements in
the seed corpus and it's blocked until every test has run.

On both cases, goleak detects them as leaking goroutines, but this are
expected goroutines.

Internal Ref: GO-2002
Fix #104

It's a known issue that goleak is incompatible with tests being run in
parallel.
* #16
* #83

Unfortunately, there is no real solution to this issue.
* #16 (comment)
* #83 (comment)
* #83 (comment)

This PR at least documents the incompatibility
and suggests using `VerifyTestMain` instead.

Instead of hand-managing and running linters, use golangci-lint.
This simplifies the Makefile and allows lint to run in parallel
with the build/test job.

Along with the golangci-lint defaults,
enable a couple other linters we generally agree with.
See also uber-go/zap#1323 and uber-go/sally#121 for similar changes.

In anticipation of parsing more information from stack traces make the
stack trace parsing logic more manageable by moving it from a state
machine into a layout closer to a recursive descent parser.

That is, instead of a central loop that reads input line-by-line
and needs to manage its various states:

    current, result := ...
    for {
        input := read()
        if cond(input) {
            result.append(current)
            current = startNew(input)
        } else {
            current = accumulate(input)
        }
    }
    result = flush(current)

Break it down so that parsing of individual results is its own function,
representing the state machine via control flow.

    result := ...
    for {
        input := read()
        if cond(input) {
            result.append(parseOne())
        }
    }

    // where

    func parseOne(input) {
        value := ...
        for ; !cond(input); input = read() {
            value = accumulate(input)
        }
        return value
    }

The net effect of this is to make the parsing logic more maintainable
once it gets more complex -- adds more states.

For example, to parse more information for individual stacks
with a state machine, we'd have to make the main loop more complex.
State for an individual stack (e.g. "all the functions in the stack")
will leak into the state management for the whole state machine.
On the other hand, with this method, we'll only modify parseStack,
keeping its responsiblity encapsulated to parsing a single stack trace.

This idea was also demonstrated recently in the first section of
[Storing Data in Control flow by Russ Cox][1].

  [1]: https://research.swtch.com/pcdata#step

---

To make it easy to write this parser, we switch from bufio.Reader
to bufio.Scanner, and wrap it with the ability to "Unscan":
basically "don't move forward on next Scan()".

Lastly, we need to bump the `go` directive in go.mod to Go 1.20
to allow use of errors.Join.

Adds support to the stack parser for reading the full list of functions
for a stack trace.

NOTE:
The function that created the goroutine
is NOT considered part of the stack.

We don't maintain the order of the functions
since that's not something we need at this time.
The functions are all placed in a set.

This unblocks #41 and allows implementing an
IgnoreAnyFunction option (similar to the stalled #80 PR).

Depends on #110

Instead of matching for built-in functions with strings.Contains,
use the parsed stack information to match function names exactly.

Following this change, the only remaining strings.Contains are
to match on the goroutine state:

```
% rg strings.Contains
utils_test.go
84:             if strings.Contains(s.State(), "run") {

internal/stack/stacks_test.go
249:            if strings.Contains(s.State(), "run") {
```

Resolves #41
Depends on #111

The CI job was renamed to ci.yml in #108
but the README.md was not updated.

Fix the badge URL in the README.

Adds a new IgnoreAnyFunction option to ignore stacks
that have the provided function anywhere in the stack,
not just the top.

To test this better, the helper blockedG.run function
was split into two.

Supersedes #80
Depends on #111

…ns (#94)" (#116)

This reverts commit 751da59.

Per discussion in #93, we don't want to release this change as-is.

### Fixed
- Built-in ignores now match function names more accurately.
  They will no longer ignore stacks because of file names
  that look similar to function names. (#112)
### Added
- Add an `IgnoreAnyFunction` option to ignore stack traces
  that have the provided function anywhere in the stack. (#113)
- Ignore `testing.runFuzzing` and `testing.runFuzzTests` alongside
  other already-ignored test functions (`testing.RunTests`, etc). (#105)

### Changed
- Miscellaneous CI-related fixes. (#103, #108, #114)

---------

Co-authored-by: Abhinav Gupta <mail@abhinavg.net>