Bug 178269

It turns out that some ASSERT_WITH_SECURITY_IMPLICATION() statements would have prevented security issues in WebKit had they been compiled into release builds.* Toward that end, I'm introducing the RELEASE_ASSERT_WITH_SECURITY_IMPLICATION() macro so that we can transition to release assertions incrementally. (Doing a wholesale change would incur performance regressions, so we want to be able to change a few at a time.) I'm also adding a webkit-style-checker (security/assertion) to suggest that new patches stop using ASSERT_WITH_SECURITY_IMPLICATION(). Q: Why not just use RELEASE_ASSERT() instead of adding RELEASE_ASSERT_WITH_SECURITY_IMPLICATION()? A: Switching from ASSERT_WITH_SECURITY_IMPLICATION() to RELEASE_ASSERT() would lose some important information that the original author thought that this assertion had security implications if it was hit. When an engineer investigates such crashes, they may be more inclined to consider the security implications of the assertion than if it were a simple RELEASE_ASSERT(). Also, if we later decide that RELEASE_ASSERT_WITH_SECURITY_IMPLICATION() no longer provides useful context, then the Tools/Scripts/do-webcore-rename script can be used to remove it relatively easily in the future. * Using -DENABLE_SECURITY_ASSERTIONS=1 when compiling WebKit will enable ASSERT_WITH_SECURITY_IMPLICATION() on release builds.