Expand and improve the "problem" tag types

[yrp604]

Two related requests:

First, when REing the analysis failures are often valuable starting spots for analysis. They can identify interesting code, show load errors, show lift errors, etc. Right now this functionality is partially implemented via certain tag types, e.g. non-code branch, unresolved indirect branch, unresolved stack adjustment, etc. However, the UI workflow here leaves something to be desired currently -- go to tag types, enable those tag types, go to tags and navigate through them.

The first request is for these analysis failures should be pushed to the users attention in some fashion. Something similar to the red X for error logs, so the user is reminded to look at the analysis failures. Pushing this to the user is somewhat critical in my opinion -- finding the failure tag after you've found the problem some other way defeats the point.

Second expand the number of problem tag types. If this is the default way unexpected analysis events are going to be communicated to the user, there are probably a bunch which could be added.

List of possible tags to add:

• Writes into read only code
• Loads from unmapped addresses
• Calling convention aberrations
• Heuristics for large amounts of dead code removal
• Branches that are constant due to memory permissions
• Branches that go into the void (cc #2381)
• Conflicting accesses sizes to structure members
• mismatched sp at basic block start (cc #1907)
• inability to populate function arguments (cc #1924)
• unknown register referenced in any IL instruction (cc #2963)
• tag places where dataflow no longer agrees with indirect branch targets
• tag places where enum types have values written to them that are not in the defined variants.

[nshp]

In a similar vein, I'd like to see a more complete IL linter sort of thing. There's a liftcheck plugin floating around from @rssor, but it only has a few tests. It seems like there are a lot of structures in the IL which display just fine, but are abnormal/unexpected and thus break analysis in mysterious little ways. For example, mixing differently-sized expressions without explicitly using a zx or sx.

[psifertex]

Note that we've created a problemlist label that we plan to work on once we've implemented #2373

Tagging all the relevant ideas with that label now, but let us know if we've missed some.