Begin v2 of the API, fixes memory usage

[evanphx]

While hunting down some memory usage issues elsewhere, I saw that, much to my chagrin, hclog was suffering from the exact memory issue issue that log/slog was designed to avoid: memory usage when the log is ignored.

As Jonathan Amsterdam points out extremely well in his presentations of slog, Go is unable to elide a ... generated slice when calling an interface function. This makes completely sense, given it has to assume it could dispatch to any number of targets.

Following in the same pattern used in slog, this PR begins a minor (but breaking) API change to correct the issue in hclog. By making Logger a struct value (that can be used as a pointer or not, it's no matter) and performing level checking before dispatching to the interface, the memory usage is elided correctly.

The benchmark included shows the memory fix as it now reports:

BenchmarkLoggerMemory-10        250033984                5.027 ns/op           0 B/op          0 allocs/op

Where as previously, it reports:

BenchmarkLoggerMemory-10        40523308                30.87 ns/op           64 B/op          1 allocs/op

There is more work to be done if we approve of this going forward, for instance, using the same technique slog uses to clean up the line calculation.

Here is Jonathan talking all about the issue that this v2 API would fix: https://youtu.be/8rnI2xLrdeM?t=1491