DOCS: IMDG Reference Manual: “Overview: topology” - minor improvements

https://github.com/hazelcast/imdg-docs/blob/master/docs/modules/overview/pages/topology.adoc

1. The advantage of the Embedded deployment is having a low-latency data access = > As I understand, low-latency is achieved though in-memory architecture (see “What is HZ IMDG: IMDG stores everything in-memory (RAM). It is designed to perform fast reads and updates”) probably, a few additional words should be added to mention that embedded could be faster than client
2. main focal point is asyncharonous or high performance computing and lots of task executions - > I’m not 100$ sure, but there is no information on benefits integrated solution could bring, app could be asynchronous or perform intensive computing without massive number of reads / writes (this is where embedded could give some advantage).
3. Hazelcast provides native clients (Java, .NET and C++), Memcache and REST clients, Python and Node.js client implementations - > Is there any difference between native client and its implementation?
4. Client/Server deployment has advantages including more predictable and reliable Hazelcast performance - > It seems, it contradicts with “The advantage of the Embedded deployment is having a low-latency data access.-” since performance is often treated as low-latency access.
5. including more predictable and reliable Hazelcast performance, easier identification of problem causes and -> That sounds like sometimes we have not-predictable performance and it is really hard to identify the problem. I guess it should be represented in more friendly way like “With C/S deployment, your performance is not influenced by any middle-ware calculations…”
6. most importantly, better scalability - > This gives an idea that every code written with embedded topology is worth scalable which is not user-friendly. It seems, “simple scalability” is enough here
7. Note that Hazelcast member libraries are available only in Java. Therefore, embedding a member to a business service, it is only possible with Java. -> Second sentence is a duplication of first one. I think it could be removed for simplicity.
8. Applications written in other languages (.NET, C++, Node.js, etc.) can use Hazelcast client libraries to access the cluster - > Not really sure, but I think, it, probably could be redesigned from technical aspect description (can use HZ clients) to something more advertising like “For non-Java solutions, HZ has developed clients in other languages ”