Implement defer

[bep]

Closes #8086

My motivation for taking on this now is that I want to try to support JS code splitting, and that would need some more powerful "post build" synchronization than what we have today. This PR would eventually, I guess, replace resources.PostProcess. This PR needs more testing/polishing, but on the technical level this is simpler and without the many restrictions of resources.PostProcess.

A typical use case for resources.PostProcess is TailwindCSS where we need to know the CSS classes etc. in use before we can build the CSS.

Written using the new defer keyword, the TailwindCSS setup could look something like this:

 {{ with (templates.Defer (dict "key" "styles" "data" "foo")) }}
      {{ $options := dict "inlineImports" true }}
      {{ $styles := resources.Get "css/styles.css" }}
      {{ $styles = $styles | resources.PostCSS $options }}
      {{ if hugo.IsProduction }}
        {{ $styles = $styles | minify | fingerprint }}
      {{ end }}
      <link href="{{ $styles.RelPermalink }}" rel="stylesheet" />
 {{ end }}

• defer only works with with
• It takes an option map as its argument. Options:
  • key: This is optional and can be thought about as being part of the cache key. In the example above, the defer block will be executed exactly once and then reused.
  • data: This becomes the "dot" in the defer block.

Note that variables defined on the outside are not visible on the inside and vice versa. Any data must be passed in the data option, e.g.:

{{ $data := dict "page" . }}
{{ with (defer (dict "data" $data)) }}
   Page: {{ .page.Title }}
{{ end }}

[bep]

@jmooring does the API as outlined above make sense to you?

[jmooring]

I think the above is OK, but this caught my attention:

defer only works with with

If that's the case, and if you anticipate that it will always be used this way, could we just have a defer block where the with is implied?

Not a big deal, but it may be easier to comprehend the intent.

[bep]

defer block where the with is implied?

So, I thought about that, but

1. The Go template parser would throw an error.
2. It would also certainly break automatic code formatting.

The first one is the deal breaker (unless we do string replacements), but the second bullet is also important (to me, anyhow).

[jmooring]

I thought about that

Yeah, I figured you did. LGTM. Things move fast in Hugo land.

[jmooring]

I assume you should not be able use defer within a content adapter. For example, to defer content adapter page creation until the other pages are rendered.

[bep]

I assume you should not be able use defer within a content adapter.

No, that would not make sense.

[bep]

I must say that this works incredibly well with my new TailwindCSS setup in bep/hugo-starter-tailwind-basic#18