feat: add mux tracer for native call tracer and native prestate tracers

[0xmountaintop]

1. Purpose or design rationale of this PR

1. continued work based on [DO NOT MERGE] hack to use native tracers #557. background see Add call and prestate tracer to l2trace code #594
2. have to upgrade go version because eth/tracers/native/prestate.go uses some new go feature
3. then need to upgrade golangci-lint because the previous version isn't compatible with go1.20
4. use interface and move core/trace.go to avoid import cycle
5. suggest ignoring lint CI now, because most of the hints make little sense, and the formatting introduces a lot of diff

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1206379435126548

[lispc]

i think after this PR, traces only add more field but not remove existed fields. So in thoery it should be compatible with existed prover? @HAOYUatHZ

[0xmountaintop]

i think after this PR, traces only add more field but not remove existed fields. So in thoery it should be compatible with existed prover? @HAOYUatHZ

yes this PR is compatible (see https://scrollco.slack.com/archives/C05UJL77FAR/p1705908908525729?thread_ts=1704082609.850259&cid=C05UJL77FAR)

but after we "disable stack", it will be incompatible and circuits need to be upgraded