When we are building WASM we don't build the browser subdirectory

This is how I imagine that this stuff should work:

- In one tree you build with --host=wasm32-local-emscripten. This
  results in only the WASM binary being built, containing C++ code
  from Collabora Office core and C++ code from Online (to a similar
  extent as in the iOS, Android, and gtk apps). No HTML and JS for the
  client's browser is produced in this tree. The embedded filesystem
  from the corresponding WASM core build could be copied into this
  tree for use as below. (Or, alternatively the build in the other
  tree could look into the config.status file in this tree to figure
  out where to pick up the embedded fs data file.)

- In another tree you build with --with-wasm-fallback=<path to the
  above WASM tree>. Note that the C++ code will be built normally in
  this case, for Linux. This build results in an otherwise normal COOL
  build, with the added feature that the COOL server sends the whole
  document file also to the COOL client whenever it is saved. The HTML
  and JS browser code will have code that enables receiving the
  document in this case, plus incremental updates to the document (if
  possible), and code to detect that the connection to the COOL server
  is broken and then fall back to using the local WASM in the
  browser. Obviously the WASM binary and related JS and other data
  (like the embedded file system from core) will have to be downloaded
  into the client right at the start, to be present if the connection
  breaks, but the WASM will likely not need to be started until
  needed.

Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I945c93451d3f5f0b1bc6ad8550da64e8e6453b6b

Makefile.am

@@ -6,7 +6,7 @@ if ENABLE_GTKAPP
 SUBDIRS = gtk browser
 else
 if ENABLE_WASM
-SUBDIRS = wasm browser
+SUBDIRS = wasm
 else !ENABLE_WASM
 SUBDIRS = browser
 endif !ENABLE_WASM