Collection of pending improvements for relocation infrastructure

[mstoodle]

#2978 identified a few weaknesses of the relocation infrastructure were identified that should really be cleaned up. I created this issue so we can track the specific changes needed in OMR so hopefully we can move forward over time without accumulating much more technical debt in this area.

I'll tag this with the "Enhancemant" label which doesn't sound necessary, but I would like to make progress on some of these items in the near term because the technical debt seems to be mounting and I'd like to put some things in place to get us on a downward trend. I have some verbal agreement from OpenJ9 project members to devote some time to this effort so we can hopefully make some progress on these items.

1. All platforms should have consistent support for all AOT features (including the new symbol validation manager introduced by OpenJ9. It would be nice to see the symbol manager concept brought into OMR as an extensible base with all the OpenJ9 specific validations moved into OpenJ9.

2. The code generators currently have an independent understanding of the structure of relocation records compared to the runtime code. The code generators should really consolidate their *AheadOfTimeCompile.cpp implementations on a single version that is backed by code at primarily RelocationRecord.cpp.

3. It would be really nice if AOT relocations could be added in the consuming project rather than in OMR itself. This would suggest some kind of extensibility be introduced into the Relocation* classes and also into the single implementation for relocation record generation roughly described in # 1, above. Extensibility would make it much easier for OpenJ9 to make additions here without having to create dependent pull requests in OMR.

4. ...