Deprecate AssertPropertyLike.createIntrinsic

[jackkoenig]

Companion to #4058

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• API deprecation

Desired Merge Strategy

• Squash

Release Notes

It should never have been a public API.

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[dtzSiFive]

LGTM!

Is the plan that this reaches everything "now", with the move to protected hitting as-of 7? If so, great! 👍

[jackkoenig]

Is the plan that this reaches everything "now", with the move to protected hitting as-of 7? If so, great!

Yep!

Our API modification policy isn't well articulated so I'm gonna give it a go here (and then maybe move it to CONTRIBUTING.md)

1. Avoid breaking things
2. For big changes or changes to popular APIs, deprecate/warn on major version and do not remove/change until next major version (if maintaining old behavior is low burden, then maybe even keep for several major versions).
3. For small changes or changes to unpopular/experimental APIs, deprecate on minor version and change in major version

This change is definitely a category (3) so no reason to delay.