Usage clarification of the group-timeout property

Added some clarification on the usage of  the group-timeout property based on discussion 
https://stackoverflow.com/questions/48230453/issue-with-spring-integration-aggregator-group-timeout-value

* Update aggregator.adoc

Fixed according to one sentence per line rule.

Author: warbabun

src/reference/asciidoc/aggregator.adoc

@@ -470,7 +470,8 @@ By default, an internal `DefaultLockRegistry` is used.
 Use of a distributed `LockRegistry`, such as the `ZookeeperLockRegistry`, ensures only one instance of the aggregator can operate on a group concurrently.
 See <<./redis.adoc#redis-lock-registry,Redis Lock Registry>>, <<./gemfire.adoc#gemfire-lock-registry,Gemfire Lock Registry>>, and <<./zookeeper.adoc#zk-lock-registry,Zookeeper Lock Registry>> for more information.
 <21> A timeout (in milliseconds) to force the `MessageGroup` complete when the `ReleaseStrategy` does not release the group when the current message arrives.
-This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout.
+This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout which counts from the time the last message arrived. 
+To set up a timeout which counts from the time the `MessageGroup` was created see `group-timeout-expression` information.
 When a new message arrives at the aggregator, any existing `ScheduledFuture<?>` for its `MessageGroup` is canceled.
 If the `ReleaseStrategy` returns `false` (meaning do not release) and `groupTimeout > 0`, a new task is scheduled to expire the group.
 We do not advise setting this attribute to zero (or a negative value).
@@ -485,7 +486,9 @@ Used for scheduling the `MessageGroup` to be forced complete.
 If the expression evaluates to `null`, the completion is not scheduled.
 If it evaluates to zero, the group is completed immediately on the current thread.
 In effect, this provides a dynamic `group-timeout` property.
-See `group-timeout` for more information.
+As an example, if you wish to forcibly complete a `MessageGroup` after 10 seconds have elapsed since the time the group was created you might consider using the following SpEL expression: `timestamp + 10000 - T(System).currentTimeMillis()` where `timestamp` is provided by `MessageGroup.getTimestamp()` as the `MessageGroup` here is the `#root` evaluation context object.
+Bear in mind however that the group creation time might differ from the time of the first arrived message depending on other group expiration properties' configuration.
+See `group-timeout` for more information. 
 Mutually exclusive with 'group-timeout' attribute.
 <23> When a group is completed due to a timeout (or by a `MessageGroupStoreReaper`), the group is expired (completely removed) by default.
 Late arriving messages start a new group.