DOCS Clarify cascade publish/delete perm checks

We decided during implementation not to check permissions explicitly on cascading objects due to performance concerns.
For example, when publishing a page with embedded images, publish permissions on the image are implied - even if Image->canPublish() would return false for this author.

See https://github.com/silverstripe-security/security-issues/issues/57

docs/en/02_Developer_Guides/00_Model/02_Relations.md

@@ -511,6 +511,11 @@ If your object is versioned, cascade_deletes will also act as "cascade unpublish
 on a parent object will trigger unpublish on the child, similarly to how `owns` causes triggered publishing.
 See the [versioning docs](/developer_guides/model/versioning) for more information on ownership.
 
+<div class="alert" markdown="1">
+Declaring cascade_deletes implies delete permissions on the listed objects.
+Built-in controllers using delete operations check canDelete() on the owner, but not on the owned object.   
+</div>
+
 ## Cascading duplications
 
 Similar to `cascade_deletes` there is also a `cascade_duplicates` config which works in much the same way.

docs/en/02_Developer_Guides/00_Model/10_Versioning.md

@@ -63,6 +63,12 @@ SilverStripe makes this possible by using the concept of _cascade publishing_. Y
 
 A non-recursive publish operation is also available if you want to publish a new version of a object without cascade publishing all its children.
 
+<div class="alert" markdown="1">
+Declaring ownership implies publish permissions on owned objects.
+Built-in controllers using cascading publish operations check canPublish()
+on the owner, but not on the owned object.   
+</div>
+
 #### Ownership of unversioned object
 
 An unversioned object can own other versioned object. An unversioned object can be configured to automatically publish children versioned objects on save.