docs/design: move pictures to imgs && other tiny refinement (pingcap#…

…10438)

* change IndexMerge proposal title
* add proposal links in README.md
* move links of the three proposals to the completed part
* fix endline of proposal "access a table using multiple indexes"
* move ddl and table partion to the completed part

docs/design/2018-07-19-row-format.md

@@ -16,7 +16,7 @@ In the current row format, each column is encoded with the column ID followed by
 
 The new format is defined as follows:
 
-![row-format](./row-format.jpeg)
+![row-format](./imgs/row-format.jpeg)
 
 * 1 byte codec version
 

docs/design/2018-08-10-restore-dropped-table.md

@@ -1,5 +1,5 @@
 
-# Proposal: 
+# Proposal: A new command to restore dropped table 
 
 - Author(s):    [winkyao](https://github.com/winkyao)
 - Last updated:  2018-08-10

docs/design/2018-08-29-new-planner.md

@@ -60,7 +60,7 @@ the future.
   With the concept of **Group** and **Group Expression**, all the logically
   equivalent expressions can be stored in a root Group.
 
-  ![group and expression](./group-and-expression.png)
+  ![group and expression](./imgs/group-and-expression.png)
 
 - **Transformation Rule**
 

docs/design/2018-10-08-online-DDL.md

@@ -27,7 +27,7 @@ DDL jobs have multiple state changes during processing. All TiDB servers in a cl
 So you can simply think that each TiDB server needs two modules to ensure that this condition is met. 
 * One is the load schema module. In order to process SQL normally, each TiDB server needs to be loaded into the latest schema within a lease. 
 * The other one is the handle DDL job module. This module is executed only after the current TiDB server is elected to the owner. Process the job and change the schema. After the owner writes the currently changed schema state to TiKV, we can assume that all TiDB servers in the cluster that can handle SQL after waiting for 2*lease have been updated to this schema.
-![Figure 1: Structure flow chart](./structure-flow-chart.png)
+![Figure 1: Structure flow chart](./imgs/structure-flow-chart.png)
 
 <font size=1 face="黑体"><center>Figure 1: Structure flow chart</center></font>
 #### Initial configuration
@@ -55,7 +55,7 @@ There are many operations in DDL that need to delete data, such as drop table re
 ### Parallel flow
 Currently, only the add index operation in TiDB takes a long time to execute, so an add index operation may block other DDL operations. In order to solve this problem preliminarily and steadily, we have implemented the parallel operation between the general operation and the add index operation between the tables. That is, between different tables, the general operation and the add index operation can be performed in parallel.
 
-![Figure 2: Owner detail flow chart](./owner-detail-flow-chart.png)
+![Figure 2: Owner detail flow chart](./imgs/owner-detail-flow-chart.png)
 
 <font size=1 face="黑体"><center>Figure 2: Owner detailed flow chart</center></font>
 ## Optimization function

docs/design/2018-10-22-the-column-pool.md

@@ -52,7 +52,7 @@ implemented as a last in first out stack, which helps to release the unused
 column in the pool. And in most cases, the required length of a new column is
 equal to the previous column put into the column pool.
 
-![the column pool](./the-column-pool.png)
+![the column pool](./imgs/the-column-pool.png)
 
 ## Rationale