When converting a negative number e.g., -2, the resulting ABI encoding
should look as follows:
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe.
However, since the check of the type is for an uint instead of an
int, it results in the following ABI encoding:
0101010101010101010101010101010101010101010101010101010101010102. The
Ethereum ABI
(https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) says,
that signed integers are stored in two's complement which should be
of the form ffffff.... and not 01010101..... for e.g. -1. Thus, I
removed the type check in numbers.go as well as the function S256
as I don't think they are correct. Or maybe I'm missing something?

Previously it was assumed that wheneven type `[]interface{}` was given
that the interface was empty. The abigen rightfully assumed that
interface slices which already have pre-allocated variable sets to be
assigned.

This PR fixes that by checking that the given `[]interface{}` is larger
than zero and assigns each value using the generic `set` function (this
function has also been moved to abi/reflect.go) and checks whether the
assignment was possible.

The generic assignment function `set` now also deals with pointers
(useful for interface slice mentioned above) by dereferencing the
pointer until it finds a setable type.

Refactored the abi package parsing and type handling. Relying mostly on
package reflect as opposed to most of our own type reflection. Our own
type reflection is still used however for cases such as Bytes and
FixedBytes (abi: bytes•).

This also inclused several fixes for slice handling of arbitrary and
fixed size for all supported types.

This also further removes implicit type casting such as assigning,
for example `[2]T{} = []T{1}` will fail, however `[2]T{} == []T{1, 2}`
(notice assigning *slice* to fixed size *array*). Assigning arrays to
slices will always succeed if they are of the same element type.

Incidentally also fixes #2379

- Sign takes common.Address, not Account
- Import/Export methods work with encrypted JSON keys

In order to avoid disk thrashing for Accounts and HasAccount,
address->key file mappings are now cached in memory. This makes it no
longer necessary to keep the key address in the file name. The address
of each key is derived from file content instead.

There are minor user-visible changes:

- "geth account list" now reports key file paths alongside the address.
- If multiple keys are present for an address, unlocking by address is
  not possible. Users are directed to remove the duplicate files
  instead. Unlocking by index is still possible.
- Key files are overwritten written in place when updating the password.

- Manager.Accounts no longer returns an error.
- Manager methods take Account instead of common.Address.
- All uses of Account with unkeyed fields are converted.

The account management API was originally implemented as a thin layer
around crypto.KeyStore, on the grounds that several kinds of key stores
would be implemented later on. It turns out that this won't happen so
KeyStore is a superflous abstraction.

In this commit crypto.KeyStore and everything related to it moves to
package accounts and is unexported.

The chain maker and the simulated backend now run with a homestead phase
beginning at block 0 (i.e. there's no frontier).

This commit also fixes up #2388

Added chain configuration options and write out during genesis database
insertion. If no "config" was found, nothing is written to the database.

Configurations are written on a per genesis base. This means
that any chain (which is identified by it's genesis hash) can have their
own chain settings.