Solid3dFilletEdge has a weird/inconsistent api

[jessfraz]

so you know how on start path we eat the cmd_id as the object_id on the rust side.

well this is Solid3dFilletEdge:

pub struct Solid3dFilletEdge {
            /// Which object is being filletted.
            pub object_id: Uuid,
            /// Which edge you want to fillet.
            pub edge_id: Uuid,
            /// The radius of the fillet. Measured in length (using the same units that the current sketch uses). Must be positive (i.e. greater than zero).
            pub radius: LengthUnit,
            /// The maximum acceptable surface gap computed between the filleted surfaces. Must be positive (i.e. greater than zero).
            pub tolerance: LengthUnit,
            /// How to apply the cut.
            #[serde(default)]
            pub cut_type: CutType,
            /// The ID to use for the newly created fillet face.
            /// If not provided, the server will randomly generate one.
            #[serde(default)]
            pub face_id: Option<Uuid>,
        }

I think its more intuitive if the face_id is actually just the cmd_id like we do for others. so I made in the kcl side those the same id such that we should deprecate the face_id however we should do it in steps.

1. make the cmd_id be the face_id in the engine, this will not break the kcl side since they are the same anyways
2. we make the kcl side do None for face_id so its empty
3. we remove face_id from the api

anyways there might be a better way but that was my idea

[adamchalmers]

Yeah great idea, sgtm