feat!: Throw errors on missing inputs

[NeilFraser]

Previously generators could generate code from inputs that didn't exist and get back the empty string. This silent failure was causing problems for diagnosing issues. This PR changes the behaviour so that an error is thrown.

This will break generators which rely on the previous behaviour. Several of our demo blocks needed editing to accommodate this change.

Resolves #7665

Breaking Change

Calling statementToCode or valueToCode on inputs that don't exist will now throw an error instead of returning an empty string. If you have a block-code generator function that was intentionally doing this and relying on the old behavior, you should update it to check for the existence of the input before calling the toCode method. If you have a block-code generator that was unintentionally doing this (because you typoed the input name, for example), it will now be easier to spot your error.

[BeksOmega]

Generally LGTM! But I'm not groking the changes to the text files, so going to wait to approve until I know what that's doing :P

[BeksOmega]

Is this an unrelated change?

[NeilFraser]

Nope, it's an example of the sort of block this PR will break. This block mutates, sometimes it has an 'AT' input, sometimes not. Previously the generator would just get '' when generating from an input that doesn't exist. Now it throws an error.

[BeksOmega]

Ah ok I see, the call to getAdjusted has been wrapped in the else so it only errors in the case where we do really expect there to be an input but it doesn't exist. Is that correct?

[NeilFraser]

Yes, in the case of the dropdown being 'LAST' there is no 'AT' input, in the case of 'FROM_END' there is an 'AT' input. Generators can no longer just try generating from an input that may or may not exist.

[BeksOmega]

Is this an unrelated change?

[NeilFraser]

Nope, same as earlier change. Same block, same input (AT), different language, and completely different code path.

[BeksOmega]

Assuming my understanding is now correct, I'm going to go ahead and approve!

Didn't check if there are other blocks relying on the old behavior, so I'm trusting you caught all of 'em.

[NeilFraser]

Didn't check if there are other blocks relying on the old behavior, so I'm trusting you caught all of 'em.

These are all the ones I found. But be aware that every generator (language) is different. I can't completely guarantee that I caught every one. And of course this will break everyone out there who has similar generators on blocks that mutate.