Seperate core and contrib api files

[bbrala]

Fixes #770

1. Added new options to bleeding edge. Current behaviour is the same.
2. Trigger deprecation notice when using old parameter, did not add a version since i dont know when it will be removed
3. Added defaults as per related issue. Behaviour is the same, but can be specified.
4. Wanted to add a test for a core module, but not sure how so i didnt.

[Kingdutch]

This looks good to me (I'm still a proponent of immediately setting checkCoreDeprecatedHooksInApiFiles to true but I know Matt wants to do it in a separate minor release).

Commenting rather than explicitly approving because I don't know if we can already remove checkCoreDeprecatedHooksInApiFiles anywhere. For example from bleedingEdge.neon, in order to prevent people from getting deprecation notices for something they load from the package itself.

Not entirely sure what the difference in behaviour between bleedingEdge.neon and extension.neon is though (since the values also differ in those two files).

[mglaman]

ah this is how

[bbrala]

Just missing version, but that's OK I think?

[bbrala]

I've updated bleedingedge so when people copy that they won't get a deprecation notice.

[bbrala]

Might need an isset or something when we remove the setting? Or perhaps even now.

[bbrala]

This looks good to me (I'm still a proponent of immediately setting checkCoreDeprecatedHooksInApiFiles to true but I know Matt wants to do it in a separate minor release).

Commenting rather than explicitly approving because I don't know if we can already remove checkCoreDeprecatedHooksInApiFiles anywhere. For example from bleedingEdge.neon, in order to prevent people from getting deprecation notices for something they load from the package itself.

Not entirely sure what the difference in behaviour between bleedingEdge.neon and extension.neon is though (since the values also differ in those two files).

Good point about bleeding edge. Updated