Fix: use blocksCache instead of single blocks instance (fixes #181)

[JounQin]

pass through lint messages from other plugins

close #181

---

split part of #178

@btmills

[JounQin]

This issue will only occur when integrating with other plugins like eslint-plugin-mdx which will lint original .md files by preprocess too.

Here is the fake version for testing.

https://github.com/eslint/eslint-plugin-markdown/pull/183/files#diff-83e0a2056017ee834945f51308072e4a883a4ed96193581fe4aabc41cb98710a

[btmills]

Thanks to your discussion in #181 and https://github.com/eslint/eslint/pull/14227/files#r602802758, we can reproduce this in a test without stubbing another mdx plugin! So let's simplify this:

<!-- test.md -->

````markdown
<!-- test.md/0_0.markdown -->

```js
// test.md/0_0.markdown/0_0.js
console.log("Hello");
```
````

With that as the test input, if you configure the CLIEngine to run this plugin's processor on .md and .markdown files (the recommended config only does .md), ESLint should run the processor recursively. That should reproduce the bug without having to stub another plugin and reduce the number of moving parts in this PR.

If that doesn't work, mention me and I'll see if I can put together a reproduction case that you can use to prove this implementation works.

I'm glad you were able to fix this by keying the blocks cache on the filename. There are two implementation tweaks that I'd like to request:

1. Can you store the cache in a Map instead of an object? That's supported all the way back to Node 8.10.
2. To save memory, would it be possible to remove blocks from the cache once postprocess() is done with them?

[JounQin]

@btmills All done!

[btmills]

Thanks for working so hard to get this down to just the essential components! I'm really happy with where it ended up. LGTM.

[JounQin]

@btmills Any schedule for a release then?

[btmills]

Now! https://github.com/eslint/eslint-plugin-markdown/releases/tag/v2.0.1