esbuild 0.11.17

Fix building with a large stdin string with Deno (#1219)

When I did the initial port of esbuild's node-based API to Deno, I didn't realize that Deno's write(bytes) function doesn't actually write the provided bytes. Instead it may only write some of those bytes and needs to be repeatedly called again until it writes everything. This meant that calling esbuild's Deno-based API could hang if the API request was large enough, which can happen in practice when using the stdin string feature. The write API is now called in a loop so these hangs in Deno should now be fixed.
Add a warning about replacing this with undefined in ESM code (#1225)

There is existing JavaScript code that sometimes references top-level this as a way to access the global scope. However, top-level this is actually specified to be undefined inside of ECMAScript module code, which makes referencing top-level this inside ESM code useless. This issue can come up when the existing JavaScript code is adapted for ESM by adding import and/or export. All top-level references to this are replaced with undefined when bundling to make sure ECMAScript module behavior is emulated correctly regardless of the environment in which the resulting code is run.

With this release, esbuild will now warn about this when bundling:
```
 > example.mjs:1:61: warning: Top-level "this" will be replaced with undefined since this file is an ECMAScript module
    1 │ export let Array = (typeof window !== 'undefined' ? window : this).Array
      ╵                                                              ~~~~
   example.mjs:1:0: note: This file is considered an ECMAScript module because of the "export" keyword here
    1 │ export let Array = (typeof window !== 'undefined' ? window : this).Array
      ╵ ~~~~~~
```
This warning is not unique to esbuild. Rollup also already has a similar warning:
```
(!) `this` has been rewritten to `undefined`
https://rollupjs.org/guide/en/#error-this-is-undefined
example.mjs
1: export let Array = (typeof window !== 'undefined' ? window : this).Array
                                                                ^
```
Allow a string literal as a JSX fragment (#1217)

TypeScript's JSX implementation allows you to configure a custom JSX factory and a custom JSX fragment, but requires that they are both valid JavaScript identifier member expression chains. Since esbuild's JSX implementation is based on TypeScript, esbuild has the same requirement. So React.createElement is a valid JSX factory value but ['React', 'createElement'] is not.

However, the Mithril framework has decided to use "[" as a JSX fragment, which is not a valid JavaScript identifier member expression chain. This meant that using Mithril with esbuild required a workaround. In this release, esbuild now lets you use a string literal as a custom JSX fragment. It should now be easier to use esbuild's JSX implementation with libraries such as Mithril.
Fix metafile in onEnd with watch mode enabled (#1186)

This release fixes a bug where the metafile property was incorrectly undefined inside plugin onEnd callbacks if watch mode is enabled for all builds after the first build. The metafile property was accidentally being set after calling onEnd instead of before.