Go back to atomic for next element serial number

This reverts commit 7bc3a9eeae.

I'd hoped that `thread_local!` would force our code to be single-
threaded, but apparently it doesn't. With a global mutable static, it
seems like we have to include some kind of thread-safety to avoid
`unsafe` code, and an atomic provides the kind of safety we actually
want.

app-proto/src/assembly.rs

@@ -1,7 +1,7 @@
 use nalgebra::{DMatrix, DVector};
 use rustc_hash::FxHashMap;
 use slab::Slab;
-use std::{cell::Cell, collections::BTreeSet};
+use std::{collections::BTreeSet, sync::atomic::{AtomicU64, Ordering}};
 use sycamore::prelude::*;
 use web_sys::{console, wasm_bindgen::JsValue}; /* DEBUG */
 
@@ -13,9 +13,7 @@ pub type ConstraintKey = usize;
 
 pub type ElementColor = [f32; 3];
 
-thread_local! {
-    static NEXT_ELEMENT_SERIAL: Cell<u64> = Cell::new(0);
-}
+static NEXT_ELEMENT_SERIAL: AtomicU64 = AtomicU64::new(0);
 
 #[derive(Clone, PartialEq)]
 pub struct Element {
@@ -41,17 +39,13 @@ impl Element {
         color: ElementColor,
         representation: DVector<f64>
     ) -> Element {
-        // take the next serial number
-        let serial = NEXT_ELEMENT_SERIAL.get();
-        NEXT_ELEMENT_SERIAL.set(serial.wrapping_add(1));
-        
         Element {
             id: id,
             label: label,
             color: color,
             representation: create_signal(representation),
             constraints: create_signal(BTreeSet::default()),
-            serial: serial,
+            serial: NEXT_ELEMENT_SERIAL.fetch_add(1, Ordering::SeqCst),
             column_index: 0
         }
     }