Bug: alternative_sprites in conditional blocks away from the parent behave inconsistently

[zephyris]

As alternative_sprite blocks can be placed away from their 'parent' sprites, the NML syntax implies you can do things like define alternative_sprites in a conditional block which are used only when that condition is met. For example:

replace grid_temperate_spr3981(3981, "temperate_groundtiles_gridline_8bpp.png") { template_groundtiles(0, 0, 1) }
if (climate==CLIMATE_ARCTIC) {
    alternative_sprites (grid_temperate_spr3981, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "arctic_groundtiles_gridline_bt32bpp.png") { template_groundtiles(0, 0, 1) }
}

This doesn't work as you'd expect from the code. The alternative sprites are always used irrespective of climate.

The syntax also allows some quite nonsensical definitions:

if (climate==CLIMATE_TEMPERATE) {
    replace grid_temperate_spr3981(3981, "temperate_groundtiles_gridline_8bpp.png") { template_groundtiles(0, 0, 1) }
}
if (climate==CLIMATE_ARCTIC) {
    alternative_sprites (grid_temperate_spr3981, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "arctic_groundtiles_gridline_bt32bpp.png") { template_groundtiles(0, 0, 1) }
}

Such behaviour is not possible for NewGRFs (cf. NFO specs) as alternative sprites are just one part of the definition of a single real sprite.

Some example NML and images:
redef-alternate.zip

[zephyris]

Two suggested changes:

1. As alternative_sprite definitions have the global action of providing alternative sprites for a uniquely named block of sprites, the requirement could be that they are only placed outside of conditional statements. Similar behaviour to template definition.
2. Prevent 'orphan' definitions of alternative sprites: If an alternative_sprite definition is in a conditional statement, require the 'parent' block of sprites is also defined in that conditional statement.

Option 1 is a heavy-handed change that may break existing NML which functions as expected. This would no longer be valid:

if (climate==CLIMATE_TEMPERATE) {
    replace sprite_set_1(....
    alternative_sprites (sprite_set_1, ...
}

Option 2 would prevent both syntax issues above. But, would it solve all cases?