minor fix in docs and import cleanup (lagom#1815)

docs/manual/java/guide/cluster/PersistentEntity.md

@@ -235,5 +235,5 @@ This needs a deeper explanation to understand the guarantees provided by Lagom.
 If you are familiar with [Akka Persistence](https://doc.akka.io/docs/akka/2.5/persistence.html) this process is slightly different in few places:
 
 * new commands are not processed until events are stored, the `Effect` completed and the snapshot updated (if necessary). Akka provides the same behavior and also `async` alternatives that cause new commands to be processed even before all event handlers have completed.
-* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence. snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot.
+* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence.snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot.
 

docs/manual/scala/guide/cluster/PersistentEntity.md

@@ -237,5 +237,5 @@ This needs a deeper explanation to understand the guarantees provided by Lagom.
 If you are familiar with [Akka Persistence](https://doc.akka.io/docs/akka/2.5/persistence.html) this process is slightly different in few places:
 
 * new commands are not processed until events are stored, the `Effect` completed and the snapshot updated (if necessary). Akka provides the same behavior and also `async` alternatives that cause new commands to be processed even before all event handlers have completed.
-* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence. snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot.
+* saving snapshots is an operation run under the covers _at least_ every `lagom.persistence.snapshot-after` events (see [Configuration](#Configuration) above) but "storing events atomically" takes precedence. Imagine we want a snapshot every 100 events and we already have 99 events, if the next command emits 3 events the snapshot will only be stored after event number 102 because events `[100, 101, 102]` will be stored atomically and only after it'll be possible to create a snapshot.
 

persistence-cassandra/scaladsl/src/main/scala/com/lightbend/lagom/scaladsl/persistence/cassandra/CassandraReadSide.scala

@@ -15,7 +15,7 @@ import scala.reflect.ClassTag
 /**
  * Cassandra read side support.
  *
- * This should be used to build and register readside
+ * This should be used to build and register a read side processor.
  */
 object CassandraReadSide {
 

persistence/core/src/main/scala/com/lightbend/lagom/internal/persistence/ReadSideConfig.scala

@@ -6,7 +6,6 @@ package com.lightbend.lagom.internal.persistence
 import java.util.concurrent.TimeUnit
 
 import com.typesafe.config.Config
-import play.api.Configuration
 
 import scala.concurrent.duration._