Change the "runs" parameter to "goal"

Questions about the runs parameter come up many times (e.g. [1](https://gitter.im/ethereum/solidity-dev?at=5dd19f14fd6fe41fc0a0a2a5), [2](https://gitter.im/ethereum/solidity-dev?at=60411fe422a5ce4a9132fb16)). Many cases people think runs here equals to the number of optimizer runs.

The `runs` parameter is described as "Estimated number of calls per opcode oven the lifetime of the contract." in the source code. If we strictly look at the runs parameter meaning the above, then the default of 200 means "the contract will be executed around 200 times" (of course it is more subtle than that). This probably is a good average value for a contract wallet. It is not a good value for a popular app.

I have not seen too many contracts where people changed from the default 200 (one notable exception is the eth2.0 deposit contract).

It perhaps may be better to consider a new setting instead: optimize for deploy-time-cost (i.e. `runs=1`) or run-time-cost (i.e. `runs=`). What is unclear what is the good "runs" value and whether very large numbers make any difference.

@ekpyron also mentioned the new low-level inline uses the same setting. Also things like Optimism (which injects code adding quite a large overhead to every single state accessing opcode) could benefit if this new setting would control the level of inlining in the codegen and optimisation steps (i.e. controlling code size).

The issue gives no file or test path; begin with the source-code description of `runs` and trace its uses in the optimizer, low-level inline handling, and codegen and optimisation steps mentioned here. Done requires an agreed replacement for the ambiguous setting and consistent behavior across those uses.

Written by the indexing model from the issue text.