Discovered some data races when analyzing logs

[vtomasr5]

If you add the -race flat to the go build command you will see some data races when running the command.

go build -race -ldflags '-X main.version=v0.6.0-20240321 -X main.repo=vtomas/hatchet' -o ./dist/hatchet main/hatchet.go

❯ ./dist/hatchet -web --merge ../mongodb_slowlogs/am11-mgo-cio1-s10_08-11-2024.log ../mongodb_slowlogs/am11-mgo-cio1-s11_08-11-2024.log
2024/10/10 11:02:13 vtomas/hatchet v0.6.0-20240321
2024/10/10 11:02:13 using database ./data/hatchet.db
2024/10/10 11:02:13 processing ../mongodb_slowlogs/am11-mgo-cio1-s10_08-11-2024.log
2024/10/10 11:02:13 hatchet name is merge_4e84d9
2024/10/10 11:02:13 fast counting ../mongodb_slowlogs/am11-mgo-cio1-s10_08-11-2024.log ...
2024/10/10 11:02:13 counted 95 lines
2024/10/10 11:02:13 creating hatchet merge_4e84d9
2024/10/10 11:02:13 using 9 threads
==================
WARNING: DATA RACE
Write at 0x00c0005224b0 by goroutine 25:
  github.com/simagix/hatchet.(*Logv2).Analyze.func1()
      /Users/vtomas/hatchet/logv2.go:252 +0x160
  github.com/simagix/hatchet.(*Logv2).Analyze.gowrap3()
      /Users/vtomas/hatchet/logv2.go:306 +0x6c

Previous write at 0x00c0005224b0 by main goroutine:
  github.com/simagix/hatchet.(*Logv2).Analyze()
      /Users/vtomas/hatchet/logv2.go:231 +0x12a4
  github.com/simagix/hatchet.Run()
      /Users/vtomas/hatchet/hatchet.go:137 +0x1790
  main.main()
      /Users/vtomas/hatchet/main/hatchet.go:20 +0x43c

Goroutine 25 (running) created at:
  github.com/simagix/hatchet.(*Logv2).Analyze()
      /Users/vtomas/hatchet/logv2.go:249 +0x16d4
  github.com/simagix/hatchet.Run()
      /Users/vtomas/hatchet/hatchet.go:137 +0x1790
  main.main()
      /Users/vtomas/hatchet/main/hatchet.go:20 +0x43c
==================

Also if some log file is empty, I get an EOF error.

❯ touch empty.log
❯ ./dist/hatchet -web empty.log
2024/10/10 11:11:03 vtomas/hatchet v0.6.0-20240321
2024/10/10 11:11:03 using database ./data/hatchet.db
2024/10/10 11:11:03 processing empty.log
2024/10/10 11:11:03 hatchet name is empty_f47030
2024/10/10 11:11:03 EOF

I think this EOF should be handled and ignore the file instead of failing.

Thank you for doing this.