Reduce memory allocations in decode_cef processor

[andrewkroh]

What does this PR do?

Change the input parameter of the cef parser to accept a string instead of []byte to avoid unnecessary copies. Data is still copied from the input message when it contains escape sequences, but otherwise a slice of the original message is used.

Another minor improvement is to allocate the map for the CEF extensions up front based on the
estimated number of extension fields.

Results from go test -run none -bench . -benchtime 5s -benchmem . before and after:

$ benchcmp before.txt after.txt
benchmark                              old ns/op     new ns/op     delta
BenchmarkProcessorRun/short_msg-12     4833          4684          -3.08%
BenchmarkProcessorRun/long_msg-12      55724         52493         -5.80%

benchmark                              old allocs     new allocs     delta
BenchmarkProcessorRun/short_msg-12     55             41             -25.45%
BenchmarkProcessorRun/long_msg-12      349            219            -37.25%

benchmark                              old bytes     new bytes     delta
BenchmarkProcessorRun/short_msg-12     3728          3424          -8.15%
BenchmarkProcessorRun/long_msg-12      26929         21173         -21.37%

(On my Macbook Intel Core i9 2.9 GHz, that's 213.4K EPS for short messages and 19.0K EPS for long messages.)

Why is it important?

For short CEF messages the processor is fast, but with longer messages with lots of extensions it starts to slow down.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works