Allow subgraphs to trigger on the constructor invoked during contract creation

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Subgraphs can not trigger on the constructor invoked during contract creation

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

What is the expected behavior?
Ability to call a mapping function based on the inputs to the constructor during contract creation

Here is the feature plan:

The primary decision for this features is figuring out how to let users define a trigger on contract creation. There are two options so far:

(1) Contract creation triggers are folded into call handlers, and the call handler for contract creation would look like this:

callHandlers:
  - function: constructor(address,uint256)
     handler: handleContractConstruction

(2) Contract creation triggers are their own trigger type and look like this:

deployHandler:
  handler: handleContractCreation

Right now we search the execution traces returned by parity-ethereum which are associated with the data source by filtering out any trace for a call and checking the first four bytes of call input for a contract method identifier which the subgraph registered a call handler for.

Although contract creation can be thought of as calling the constructor method, the way the transaction is constructed and the EVM executes it is different. For starters, the call to create a contract has a NULL to property and the constructor code is passed to the EVM in the call without a corresponding method identifier. For those reasons I think we should expose deployment triggers using the subgraph yaml pattern in (2).

These are the required changes to implement this:

(1) Update graph-cli with the extensions to the yaml
(2) Update json-rpc-server to deserialize and save the new deployment handler for datasources
(3) Update BlockStream to scan traces for deployment triggers and send these deployment triggers along to the consumer
(4) Update RuntimeHost with a process_deployment method which can parse the input for a contract creation transaction for the params to the constructor
(5) Update RuntimeHost to construct a new EthereumContractDeployment object for the WASM handler
(6) Update SubgraphInstances process_trigger to handle the new EthereumTrigger::Deployment
(7) Update SubgraphInstanceManager to reprocess any dynamic data sources created in the block for deployment triggers
(8) Update graph-ts with the EthereumContractDeployment object which handlers will use as input to their mapping functions