Handle shared cache and kernel cache TEXT __const section as possibly writable

[emesare]

It appears that in certain cases we should be treating the __const section in the TEXT segment as writable, looking at other analysis tools it is not always writable so there is some other factor for when we should do this. The driving factor behind this change is that some loader initialized data is being stored in that section and the uninitialized data we are presenting is being picked up by analysis and used in constant value propagation, eliminating code paths and otherwise tainting analysis.

[emesare]

Related: #6717 we should be able to mark the data in that section as volatile, however some of this data is structures / enums which we currently do not parse correctly.

[emesare]

For users trying to do this themselves (mark the section as writable) they will run into the issue that the segment permissions (r-x) supersede that of the section semantics.

This means that the user cannot prevent constant value propagation from the uninitialized data variables, without retyping each one as volatile, which because of #6717 is not actually possible.

As an aside, we have no concept of variable attributes (either in analysis or in data variables) so we cant even markup the variable as volatile independent of the associated type.

[emesare]

Solutions:

1. Provide a psuedo-segment to cover TEXT __const sections, that way we don't need to fight the segment permissions to make the section writable.
2. Markup all data-variables as volatile, and provide some easy keybind to adjust data variable types, and do Volatile structure support #6717.
3. Prioritize sections over segments in IsOffsetWritableSemantics allowing the user to actually mark the __const section as writable.

I am partial to 3 as it is instinctively the first thing a user would reach for and do. 1 would have the same effect but would cause a lot of special casing in code that otherwise is broad and not opinionated. 2 is the most granular and should be done regardless IMO.

The issue with 3 is currently that code is "correct" from the perspective of a "access rights" of the memory page, to make the section supersede the segment.