Expand var compatibility test for active attribute

[dustinswales]

This PR expands the existing var_compatibility_test to test the functionality of the "active" attribute.

User interface changes? No

Addresses #432

Screenshot of autogenerated code:

[gold2718]

Please fill in the PR header. I'm not understanding how this addresses #432.

[dustinswales]

@gold2718 Not sure what else to put in there? (There's a code snippet of the correctly autogenerated code)

[dustinswales]

Can you tell me why the autogenerated code has the if (.true.) blocks?

I'm not sure why those lines are in there. Maybe @climbfuji knows their history and/or importance They are unnecessary and make the code tedious to look at.

I just pushed a changed that removes them. For example:

[climbfuji]

The if (.true.) blocks are there just because it's easier to code - in prebuild, we don't have such a nice way to deal with indentation, therefore it makes like a lot easier to keep it the same regardless of the if condition. But, if you can do away with in in capgen, then that's much better of course!

[dustinswales]

The if (.true.) blocks are there just because it's easier to code - in prebuild, we don't have such a nice way to deal with indentation, therefore it makes like a lot easier to keep it the same regardless of the if condition. But, if you can do away with in in capgen, then that's much better of course!

@climbfuji This makes sense. Thanks for the history. And adios extra lines! @gold2718 @peverwhee Are we okay to proceed with this PR?

[climbfuji]

@dustinswales Can you confirm that after removing the if (.true.) then blocks, the if statements are still there if the active attribute is not the default .true.?

[dustinswales]

Extension of the auto-generated code snippet from above:

[climbfuji]

Extension of the auto-generated code snippet from above:

Great, thanks!