EIP-1900 code syntax highlighting

As suggested in #1900 (comment)

EIPS/eip-1900.md

@@ -52,7 +52,7 @@ A type definition consists of a type library containing:
 
 A simple example is:
 
-```
+```solidity
 pragma solidity ^0.5.0;
 pragma experimental ABIEncoderV2;
 
@@ -82,7 +82,7 @@ library myBalanceLib {
 
 Types can also use existing types in their composition. However, this will always result in a directed acyclic graph.
 
-```
+```solidity
 library myTokenLib {
     using myBalanceLib for myBalanceLib.myBalance;
 
@@ -111,7 +111,7 @@ Type metadata will be registered on-chain, in the dType registry contract. This
     - `["2","3"]` -> `TypeA[2][3]`
 
 Examples of metadata, for simple, value types:
-```
+```javascript
 {
   "contractAddress": "0x0000000000000000000000000000000000000000",
   "typeChoice": 0,
@@ -130,7 +130,7 @@ Examples of metadata, for simple, value types:
 ```
 
 Composed types can be defined as:
-```
+```javascript
 {
   "contractAddress": "0x105631C6CdDBa84D12Fa916f0045B1F97eC9C268",
   "typeChoice": 0,
@@ -144,7 +144,7 @@ Composed types can be defined as:
 ```
 
 Composed types can be further composed:
-```
+```javascript
 {
   "contractAddress": "0x91E3737f15e9b182EdD44D45d943cF248b3a3BF9",
   "typeChoice": 0,
@@ -163,7 +163,7 @@ Composed types can be further composed:
 
 To store this metadata, the dType registry will have the following data structures:
 
-```
+```solidity
 enum TypeChoices {
     BaseType,
     PayableFunction,
@@ -191,7 +191,7 @@ struct dType {
 
 For storage, we propose a pattern which isolates the type metadata from additional storage-specific data and allows CRUD operations on records.
 
-```
+```solidity
 // key: identifier
 mapping(bytes32 => Type) public typeStruct;
 
@@ -210,7 +210,7 @@ Initially, single word English names can be disallowed, avoiding name squatting.
 
 The dType registry interface is:
 
-```
+```solidity
 import './dTypeLib.sol';
 interface dType {
     event LogNew(bytes32 indexed identifier, uint256 indexed index);