Consider merging the readonly-* rules

[jonaskello]

Instead of having separate readonly-interface, readonly-indexer, and readonly-array rules we could merge them into one rule readonly which could have options for ignore-interface, ignore-indexer, ignore-array. This would probably speed things up a bit as we only need to traverse the AST once. Also having fewer rules could be a considered an advantage.

[jonaskello]

It would probably make more sense to merge readonly-interface and readonly-indexer since both are based on the readonly keyword. But readonly-array is based on the ReadonlyArray<T> type so it should probably be its own rule.

[jonaskello]

So we could have a readonly-keyword rule that would enforce the use of the readonly keyword in all places it is allowed. So the first thing is to find all places wherereadonly is allowed. However I cannot find an updated version of the typescript language specification that includes this. So I'll try to collect them here:

Interface members (including indexers):

interface Foo {
  readonly bar: string,
  readonly [key: string]: string,
}

Object type alias members (including indexers):

type Foo = {
  readonly bar: string,
  readonly [key: string]: string,
}

Object type literals (including indexers):

let foo: { readonly bar: string, readonly [key: string]: string}; 

Class members (we don't want to support this?)

class Circle {
  readonly radius: number;
}

[jonaskello]

It seems that in all of the above cases, the type of nodes allowing readonly are the same. They are either PropertySignature or IndexSignature.

So maybe a check for readonly on all PropertySignature and IndexSignature nodes will work. And perhaps it can be done regardless of where those nodes are found.

[jonaskello]

This is the only official mention of where readonly is allowed I can find. It seems to support the theory that readonly is allowed on PropertySignature and IndexSignature nodes:

A property or index signature can now be declared with the readonly modifier

[jonaskello]

Continued in #31.