initialize state with all elements that appear in GEN-INFO blocks not…

[rburghol]

@PaulDudaRESPEC This is OK to merge (all tests passed). This fixes an error reported in #179 where a SPEC-ACTIONS was looking for a RCHRES that did not exist in state. As it turns out, this was not really a SPEC-ACTIONS execution error, but rather something that should have been caught earlier in the runtime setup for SPEC-ACTIONS:

• Following HSPF behavior only items in the OPN SEQUENCE block are loaded at runtime by HSP2 but convention allowed segments in GEN-INFO blocks to remain as inactive.
• After reviewing HSPsquared model created from ./tests/ZRW_WestIndian/HSPF.uci fails with KeyError #179 and discussing with @timcera -- he noted that HSPF had this permissive behavior for inactive GEN-INFO entries, but would would not allow SPEC-ACTIONS to reference inactive segments.
• The latest commits preserve that HSPF behavior such that UCI in 179 above fail with an error message describing the problem. like Exception: Missing/inactive segment RCHRES 110 referenced in SPECIAL ACTIONS. Quitting.
• The code is set so that if you decide, it can simply warn "Hey, HSPF wouldn't let you do this, but HSP2 is OK with it, but these special actions will be ignored", and then continue on.

[PaulDudaRESPEC]

@rburghol , you are reading that right. If a user wants to remove an operation from a simulation, it is legitimate and common for instance to 'comment out' that line of the OPN SEQUENCE block and then every occurrence of that operation is ignored throughout the UCI.

[rburghol]

Thanks @PaulDudaRESPEC - so then any special actions that refer to things that are NOT in the OPN SEQUENCE should be ignored at runtime?
If so, I think I should reverse this fix, and instead insure that the special action loading at runtime only loads those SAs that have enabled inputs.

IF you could confirm that logic I'd appreciate it (or disabuse me of my errors).

[PaulDudaRESPEC]

@rburghol , I confirm that logic.