Bugfix: numArguments cap and ConsumeUint8 bounds check

[oioio-space]

Fixes #40.

Two independent bounds issues in evtx.go, both reachable from an untrusted
.evtx file (a log forged on a compromised host is a known anti-forensic
technique, so this is a real DoS surface for anyone parsing evidence):

1. ParseTemplateInstance reads numArguments from the stream twice: once on
   the fast path (known template), and again in the !pres branch, taken
   whenever short_id has not been seen before. The existing cap
   (numArguments > 1024*10) is only applied to the first read. It does not
   protect the second — which is the read a file forged from scratch always
   reaches, since a short_id cannot be "known" without first being defined by
   that same branch. An attacker-controlled numArguments up to ~4.29e9 then
   drives the arg-header append loop unbounded. Moved the cap to apply once,
   after both possible reads, right before the value is used as a loop bound.

2. ConsumeUint8's bounds check, if self.offset > len(self.buff), is off by
   one: at offset == len(buff) the check is false, and the following
   self.buff[self.offset] indexes one past the end and panics. The sibling
   Consume* methods already use the correct form (e.g. ConsumeUint16:
   offset+2 > len(buff)); this brings ConsumeUint8 in line.

Added bounds_test.go with table-driven regression tests for both: a forged
numArguments reaching the arg-header loop through the !pres branch (checked
against both a near-uint32 max value and a value just over the cap), and
ConsumeUint8 at the exact end of the buffer and just past it. Both tests were
verified to fail against the unpatched code — the first times out, the second
panics with index out of range [8] with length 8 — and to pass against the
fix.

Two notes on scope, to keep this focused on the two defects from #40:

• Not included: a related, lower-severity issue in ConsumeBytes, which
  allocates make([]byte, size) with an attacker-controlled size on the
  out-of-bounds path instead of returning nil like every other Consume*
  method. Happy to send it separately if you'd like it.
• go test ./... has two pre-existing failures here (TestEvtx/TestCollector,
  TestEvtx/TestTemplates); they exec a ./dumpevtx binary that isn't built in
  my environment and fail identically on unmodified master. go vet likewise
  reports one pre-existing unreachable code finding at evtx.go:1033 that is
  present on master. Neither is touched by this change.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ scudette
❌ PickAName
_{You have signed the CLA already but the status is still pending? Let us recheck it.}