Request for new rule to prefer toBeFunction/toBeArray

[geoffswift]

I would expect something like this to be flagged in error, and ideally auto-fixable

// bad
expect(example).toStrictEqual(expect.any(Function));
expect(typeof example).toBe('function');
expect(typeof example == 'function').toBeTrue();
expect(typeof example == 'function').toBeTruthy();
expect(typeof example === 'function').toBeTrue();
expect(typeof example === 'function').toBeTruthy();

expect(example).toStrictEqual(expect.any(String));
expect(typeof example).toBe('string');
expect(typeof example == 'string').toBeTrue();
expect(typeof example == 'string').toBeTruthy();
expect(typeof example === 'string').toBeTrue();
expect(typeof example === 'string').toBeTruthy();

expect(example).toStrictEqual(expect.any(Number));
expect(typeof example).toBe('number');
expect(typeof example == 'number').toBeTrue();
expect(typeof example == 'number').toBeTruthy();
expect(typeof example === 'number').toBeTrue();
expect(typeof example === 'number').toBeTruthy();

// good
expect(example).toBeFunction();

expect(example).toBeString();

expect(example).toBeNumber();

Arrays are a bit different

// bad
expect(Array.isArray(example)).toBeTrue();
expect(Array.isArray(example)).toBeTruthy();

// good
expect(example).toBeArray();

[G-Rath]

I've transferred this to eslint-plugin-jest-extended as that's where rules for jest-extended matchers belong - note we've already got some rules for toBe including toBeArray and toBeObject

[geoffswift]

I noticed the same idea suggested in #95. I think my report is more specific though, but I guess we should close one or the other.