Fix: don't throw if rule is in old format (fixes #6848)

[vitorbal]

What issue does this pull request address?
#6848: internal-no-invalid-meta was throwing an error when it ran on a rule in the old format.

What changes did you make? (Give an overview)
I changed internal-no-invalid-meta so it now reports a linting error when the rule is in the old format, instead of throwing an unrecognizable error.

Is there anything you'd like reviewers to focus on?
Nothing in particular.

[mention-bot]

@vitorbal, thanks for your PR! By analyzing the annotation information on this pull request, we identified @mysticatea to be a potential reviewer

[eslintbot]

LGTM

[gyandeeps]

LGTM, waiting for others to review.
Also I think this should be Chore since this has no impact on users.

[platinumazure]

Question: Do we want to tolerate exports assignment style? If not, should we try to lint against that in this rule?

Example:

// Header comments

// Requirements, etc.

exports.meta = {
    docs: {},
    fix: false,
    recommended: false,
    schema: []
};

exports.create = function(context) {
    // etc.
};

[platinumazure]

@gyandeeps It does impact our build tooling though, so one could argue Build: as well, I think. Personally, I'm okay with Fix: since I think I've seen it used in other internal-only/build cases. But that's just my two cents.

[mysticatea]

LGTM, thank you!

As the history of the file, Chore: seems to be proper.

[vitorbal]

@platinumazure IMO I think it would be valuable to lint against the exports assignment style you mentioned.
First, because the format suggested in the documentation is a different one, and we should maintain consistency (at least internally, if we ever expose these rules for plugins, we can revisit this).
Second, because maintaining that consistency also means the complexity of this internal rule is reduced, since we don't have to account for different "exports styles" in the rules and can cut some corners.

So I'm 👍 for linting for the correct exports format :)
Question, though: should it be a separate rule, since this one should be more focused on linting the meta property?

[ilyavolodin]

This is an internal rule that should only be used on ESLint repository, while style shown by @platinumazure is valid, it's not the style we use for our rule, and will be noted during code review. So I think this rule doesn't need to check that style. If anything, we might want to create another rule that would enforce module.exports for rules to be an object and not to use multiple module.exports statements. LGTM