Document That Descheduler Considers StatefulSets For Eviction

Similar to ReplicaSet, ReplicationController, and Jobs pods with a
StatefulSet metadata.ownerReference are considered for eviction.
Document this, so that it is clear to end users.

README.md

@@ -130,8 +130,8 @@ strategies:
 
 ### RemoveDuplicates
 
-This strategy makes sure that there is only one pod associated with a Replica Set (RS),
-Replication Controller (RC), Deployment, or Job running on the same node. If there are more,
+This strategy makes sure that there is only one pod associated with a ReplicaSet (RS),
+ReplicationController (RC), StatefulSet, or Job running on the same node. If there are more,
 those duplicate pods are evicted for better spreading of pods in a cluster. This issue could happen
 if some nodes went down due to whatever reasons, and pods on them were moved to other nodes leading to
 more than one pod associated with a RS or RC, for example, running on the same node. Once the failed nodes
@@ -546,7 +546,7 @@ strategies:
 When the descheduler decides to evict pods from a node, it employs the following general mechanism:
 
 * [Critical pods](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) (with priorityClassName set to system-cluster-critical or system-node-critical) are never evicted.
-* Pods (static or mirrored pods or stand alone pods) not part of an RC, RS, Deployment or Job are
+* Pods (static or mirrored pods or stand alone pods) not part of an ReplicationController, ReplicaSet, StatefulSet, or Job are
 never evicted because these pods won't be recreated.
 * Pods associated with DaemonSets are never evicted.
 * Pods with local storage are never evicted (unless `evictLocalStoragePods: true` is set)