Add diagram to document xilem layers (#322)

Note that this adds a link to a section added in
linebender/parley#69

I removed Taffy from the diagram for simplicity, and because Taffy's
current integration is in flux.

Overall I think the Xilem README is in desperate need of a rewrite, and
this PR should be considered a stopgap. Further PRs should better
integrate the ecosystem descriptions into the README, move some sections
around, etc.

README.md

@@ -21,7 +21,29 @@ This repo contains an experimental architecture, implemented with a toy UI. At a
 
 Discussion of Xilem development happens in the [Xi Zulip](https://xi.zulipchat.com/), specifically the [#xilem stream](https://xi.zulipchat.com/#narrow/stream/354396-xilem). All public content can be read without logging in
 
-## Overall program flow
+## Project structure
+
+This diagram gives an idea what the Xilem project is built on:
+
+![Xilem project layers](docs/assets/xilem-layers.svg)
+
+On a very coarse level, Xilem is built directly on top of xilem_core and Masonry, both of which are crates in this repository.
+
+Then Masonry is built on top of:
+
+- **winit** for window creation.
+- **Vello and wgpu** for 2D graphics.
+- **Parley** for [the text stack](https://github.com/linebender/parley#the-Parley-text-stack).
+- **AccessKit** for plugging into accessibility APIs.
+
+## Architecture
+
+See [ARCHITECTURE.md](./ARCHITECTURE.md) for details.
+
+<!--- TODO: This needs a serious refactor.
+This section should not be in the main README. -->
+
+### Overall program flow
 
 > **Warning:**
 >
@@ -44,7 +66,7 @@ These are all just vanilla data structures. The next step is diffing or reconcil
 
 The closures are the interesting part. When they're run, they take a mutable reference to the app data.
 
-## Components
+### Components
 
 A major goal is to support React-like components, where modules that build UI for some fragment of the overall app state are composed together. 
 
@@ -65,7 +87,7 @@ fn app_logic(data: &mut AppData) -> impl View<AppData, (), Element = impl Widget
 
 This adapt node is very similar to a lens (quite familiar to existing Druid users), and is also very similar to the [Html.map] node in Elm. Note that in this case the data presented to the child component to render, and the mutable app state available in callbacks is the same, but that is not necessarily the case.
 
-## Memoization
+### Memoization
 
 In the simplest case, the app builds the entire view tree, which is diffed against the previous tree, only to find that most of it hasn't changed.
 
@@ -87,7 +109,7 @@ The combination of memoization with pointer equality and an adapt node that call
 
 I anticipate it will also be possible to do dirty tracking manually - the app logic can set a dirty flag when a subtree needs re-rendering.
 
-## Optional type erasure
+### Optional type erasure
 
 By default, view nodes are strongly typed. The type of a container includes the types of its children (through the `ViewTuple` trait), so for a large tree the type can become quite large. In addition, such types don't make for easy dynamic reconfiguration of the UI. SwiftUI has exactly this issue, and provides [AnyView] as the solution. Ours is more or less identical.