Replace kittycad crate with kittycad-modeling-cmds (#3909)

lib.rs/kittycad-modeling-cmds is the source of our Modeling API. It gets included in our backend APIs, and those APIs generate OpenAPI specs which are read by `openapitor` which generates the lib.rs/kittycad crate. So basically, our modeling app is using the _generated code_ instead of the _handwritten code_.

This sucks -- if you add a new field to the modeling-api crate, you have to merge PRs to the engine, api-deux, and kittycad.rs before finally you can get the new field into the modeling-app. I was pretty embarrased when @mlfarrell asked how to get a new field into the modeling app and had to explain this whole bullshit cycle. Let's fix it.

Switching to use the kittycad-modeling-cmds (aka kcmc) crate directly should speed up our dev cycle.

src/wasm-lib/kcl/src/std/chamfer.rs

@@ -2,7 +2,10 @@
 
 use anyhow::Result;
 use derive_docs::stdlib;
-use kittycad::types::ModelingCmd;
+use kcmc::each_cmd as mcmd;
+use kcmc::length_unit::LengthUnit;
+use kcmc::{shared::CutType, ModelingCmd};
+use kittycad_modeling_cmds as kcmc;
 use schemars::JsonSchema;
 use serde::{Deserialize, Serialize};
 
@@ -137,14 +140,14 @@ async fn inner_chamfer(
         let id = uuid::Uuid::new_v4();
         args.batch_end_cmd(
             id,
-            ModelingCmd::Solid3DFilletEdge {
+            ModelingCmd::from(mcmd::Solid3dFilletEdge {
                 edge_id,
                 object_id: extrude_group.id,
-                radius: data.length,
-                tolerance: DEFAULT_TOLERANCE, // We can let the user set this in the future.
-                cut_type: Some(kittycad::types::CutType::Chamfer),
+                radius: LengthUnit(data.length),
+                tolerance: LengthUnit(DEFAULT_TOLERANCE), // We can let the user set this in the future.
+                cut_type: CutType::Chamfer,
                 face_id: Some(id),
-            },
+            }),
         )
         .await?;