dynblock,hcldec: Decode unknown dynamic block bodies as entirely unknown values

[jbardin]

The dynblock extension paired with hcldec previously used a single object with unknown attributes as a sentinel to indicate that a decoded dynamic block was unknown. This however poses multiple problems with consumers of the data which are not aware of the dynamic construct, since they may misinterpret the number of values, and can be confused when known values are mixed with the sentinel value.

Rather than using a sentinel value within the container, here we propose to ensure a decoded block container which contains any dynamic block with an unknown for_each argument will result in an entirely unknown value. This better serves the purpose of the original sentinel value, as there is no other way to assign an unknown value to a block container, and allows consumers to understand that the final container value itself is not entirely known.

We accomplish this by adding an UnknownBody interface to the hcldec package, which can be used to signal when a block should be decoded as unknown. Any body that satisfies this interface and returns true will cause the entire block container to be decoded as an unknown value, regardless of other known bodies being decoded for that particular block.

[apparentlymart]

We've been chatting directly about whether we need this separate ExpandWithUnknown entry point or if it's better to change the (arguably incorrect) behavior of the existing entry point, so we'll continue researching that, but I had a few little bits I noticed while I was reading through before we had that discussion that I just wanted to save here so I don't forget about them!

[jbardin]

Rebased with some refactoring to allow dynamic to no longer interfere with the MinItems and MaxItems validations. Removed the new entrypoint for now, with the aim of making this the default behavior. I can push that change back in if it turns out another project will be adversely affected by the change.

[apparentlymart]

This looks good to me!

The old result here was confusing and inconsistent, so I think it's justified to change it to behave more in line with the design intent, rather than staying bug-compatible. The old behavior remains for applications that aren't using unknowns, or that are using the other API entry points (the main hcl package API or gohcl), so this should only affect applications that are intentionally working with unknown values and thus should be ready to deal with unknown values in results, per our usual assumptions.