Checker performance improvements

[TristonianJones]

In assessing Checker performance there were three factors which dominated performance:

• proto.Equal (46%)
• ANTLR Lexer / Parser initialization (33%)
• checker declaration conflict detection (17%)
• other (4%)

The dominant use of proto.Equal was actually introduced in #250 to fix an infinite recursion bug. The second issue was introduced in #177 to address data races within the ANTLR runtime.

Upon further review, the use of proto.Equal in #250 could be much more narrowly scoped and the substitution logic simplified, thus significantly improving the expression compilation performance within larger applications like https://github.com/google/cel-policy-templates-go.

Before:

BenchmarkCompiler_Template/canonical-8         	      12	  96157074 ns/op	26354824 B/op	  683280 allocs/op

After:

BenchmarkCompiler_Template/canonical-8         	      19	  57289719 ns/op	21251336 B/op	  407321 allocs/op

[TristonianJones]

Note, I've submitted PR antlr/antlr4#2816 to make ANTLR's Go codegen like what we've hacked together in CEL, and to export a method that will allow us to use ANTLR Lexer / Parser objects within a sync.Pool in order amortize the construction cost while still being thread-safe.

[TristonianJones]

The bulk of performance improvements came with #520