feat: Add `std.goFormat` built-in

[julienduchesne]

I've identified that the main bottleneck in most of our jsonnet is actually string formatting It's one of the few things which haven't been ported from C-jsonnet

Here's a benchmark from the file I'm adding here and the equivalent jsonnet format:

goFormat:

julienduchesne@Juliens-MacBook-Pro go-jsonnet % time cat builtin-benchmarks/goFormat.jsonnet | ./jsonnet - | wc -l
10203
cat builtin-benchmarks/goFormat.jsonnet  0.00s user 0.00s system 54% cpu 0.011 total
./jsonnet -  0.12s user 0.02s system 142% cpu 0.098 total
wc -l  0.00s user 0.00s system 5% cpu 0.098 total

Jsonnet:

julienduchesne@Juliens-MacBook-Pro go-jsonnet % time cat builtin-benchmarks/jsonnetFormat.jsonnet | ./jsonnet - | wc -l
10203
cat builtin-benchmarks/jsonnetFormat.jsonnet  0.00s user 0.00s system 66% cpu 0.007 total
./jsonnet -  9.43s user 0.41s system 145% cpu 6.773 total
wc -l  0.00s user 0.00s system 0% cpu 6.772 total

I also looked into replicating the std.format function into go code but it seems like a monumental task, there are so many edge cases. So now, there are tons of differences between the C-style formatting and Go-style formatting so it's not a replacement but, could we have both? Go-style formatting is pretty common in the same places where jsonnet is used so it wouldn't be so out-of-place

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[CertainLach]

I also looked into replicating the std.format function into go code but it seems like a monumental task, there are so many edge cases.

It is not actually that hard, https://github.com/CertainLach/jrsonnet/blob/master/crates/jrsonnet-evaluator/src/stdlib/format.rs

If going for the go-native string formatting instead, then something should be done against T and the p specifiers at least, since they wouldn't be pure, and will break the abstraction.

If there is a need to add another templating util, why not golang's text/template instead? It is familiar to devops too, and there won't be two templating functions that behave similarly, but not in quite the same way