docs: use the correct type annotation syntax in the typing RFC

docs/RFCS/20160203_typing.md

@@ -431,9 +431,9 @@ this extension for explanatory purposes.

The extension is a new expression node "type annotation".

We also propose the following SQL syntax for this: "E : T".
We also propose the following SQL syntax for this: "E ::: T".

For example: `1:int` of `1 : int`.
For example: `1:::int` or `1 ::: int`.

The meaning of this at a first order approximation is "interpret the
expression on the left using the type on the right".
@@ -455,24 +455,24 @@ In the first pass we check the following:
  occurrences of a placeholder appear as immediate argument
  to a cast expression then:

  - if all the cast(s) are homogenous,
  - if all the cast(s) are homogeneous,
    then assign the placeholder the type indicated by the cast.

  - otherwise, assign the type "string" to the placeholder.

Examples:

```
   select $1:float, $1::string
       -> $1 : float, execution will perform explicit cast float->string
   select $1:float, $1:string
   select $1:::float, $1::string
       -> $1 ::: float, execution will perform explicit cast float->string
   select $1:::float, $1:::string
       -> error: conflicting types
   select $1::float, $1::float
       -> $1 : float
       -> $1 ::: float
   select $1::float, $1::string
       -> $1 : string, execution will perform explicit cast $1 -> float
   select $1:float, $1
       -> $1 : float
       -> $1 ::: string, execution will perform explicit cast $1 -> float
   select $1:::float, $1
       -> $1 ::: float
   select $1::float, $1
       -> nothing done during 1st pass, typing below will resolve
```
@@ -482,7 +482,7 @@ customary in SQL interpreters, that the client may choose to disregard
the stated type of a placeholder during execute and instead pass the
value as a string. The query executor must then convert the string to
the type for the placeholder that was determined during type checking.
For example if a client prepares `select $1:int + 2` and passes "123" (a string),
For example if a client prepares `select $1:::int + 2` and passes "123" (a string),
the executor must convert "123" to 123 (an int) before running the query. The
annotation expression is a type assertion, not conversion, at run-time.)

@@ -849,7 +849,7 @@ Typing of insert ends. All is well. Result:
```
       insert
       |
     10:float
    10:::float
```


@@ -881,9 +881,9 @@ Typing completes.
```
   select
    |
   floor:float
  /          \
$1:float    $2:float
  floor:::float
  /           \
$1:::float   $2:::float
```


@@ -1083,7 +1083,7 @@ Typing end with int.
#### Part c

```sql
    PREPARE a AS SELECT ($1 + 4) + $1:int
    PREPARE a AS SELECT ($1 + 4) + $1:::int
```

"$1" gets assigned "int" during the first phase.
@@ -1094,7 +1094,7 @@ Typing ends.
#### Part d

```sql
    PREPARE a AS SELECT ($2 - $2) * $1:int, $2:int
    PREPARE a AS SELECT ($2 - $2) * $1:::int, $2:::int
```

$2 is assigned int during the first pass.
@@ -1113,7 +1113,7 @@ Typing ends successfully.
### Example 12

```sql
    f : int -> int
    f ::: int -> int
    INSERT INTO t (int_a, int_b) VALUES (f($1), $1 - $2)
    -- succeeds (f types $1::int first, then $2 gets typed int),
    -- however:
@@ -1142,7 +1142,7 @@ Then typing completes.
### Example 13

```sql
  select max($1, $1):int
  select max($1, $1):::int
```

Annotation demands "int" so rule 6 demands "int" from max, resolves "int" for $1 and max.
@@ -1544,7 +1544,7 @@ expressions as long as it manages to type new placeholders. This way:
    --                              ^  fail, but continue
	--  						 $1 + $2, f($1)      continue
	--  							        ^
	--  						  ....  , f($1:int)  now retry
	--  						  ....  , f($1:::int)  now retry
	--
    --                           $1::int + $2, ...
	--  						         ^ aha! new information