fix dangling reference in parser::Parse with unique_ptr

[jbohanon]

The variable result was a dangling reference when returning from Parser::parse function due to internals of parse_into, so we create a std::unique_ptr of the template and return that instead.

This is to resolve the static analysis warning generated in our envoy repos:

analyze-build: INFO: In file included from source/extensions/filters/http/transformation/inja_transformer.cc:1:
analyze-build: INFO: In file included from ./source/extensions/filters/http/transformation/inja_transformer.h:17:
analyze-build: INFO: bazel-out/k8-fastbuild/bin/external/inja/_virtual_includes/inja-lib/inja/inja.hpp:2065:5: warning: Address of stack memory associated with local variable 'result' is still referred to by the stack variable 'parser' upon returning to the caller.  This will be a dangling reference [core.StackAddressEscape]
analyze-build: INFO:     return result;
analyze-build: INFO:     ^~~~~~~~~~~~~

[jbohanon]

Currently the Parser::parse function is called from the same scope as the Parser is itself created. With this change, if the parser were to ever outlive the returned unique_ptr from the parse function, we would run into issues again. This is because fundamentally the issue is that the underlying memory from the Template object returned from parse is accessed and depended upon by the Parser's lexer. We could solve this by stashing the unique_ptrs in a vector on the Parser, but that feels hacky

tl;dr: the returned std::unique_ptr<Template> must outlive the Parser that created it.

[yuval-k]

should we use unique_ptr here? i don't see this shared anywhere?

[jbohanon]

Great callout, thanks! Made that change

[yuval-k]

we are doing parse just on config time, right? if so i'm ok with this copy.

[jbohanon]

Yes, we are only parsing at config time. I will add a comment to the area where this is called in envoy-gloo to explicitly call out that we should only be parsing at config time.