Combine Ptr & ContPtr representation

[johnchandlerburnham]

Currently our representation of Ptr and ContPtr are nearly identical:

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct Ptr<F: LurkField> {
    /// An expression tag
    pub tag: ExprTag,
    /// The underlying pointer, which can be null, opaque, or an index
    pub raw: RawPtr,
    /// PhantomData is needed to consume the `F: LurkField` parameter, since
    /// we want to pin our Ptr to a specific field (even though we don't
    /// actually use it)
    pub _f: PhantomData<F>,
}


#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct ContPtr<F: LurkField> {
    pub tag: ContTag,
    pub raw: RawPtr,
    pub _f: PhantomData<F>,
}

and there are many duplicated methods.

We should explore combining these representations analogous to how SPtr combines ScalarPtr and ScalarContPtr (soon to be renamed ZPtr, ZExprPtr, ZContPtr)

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[cfg_attr(not(target_arch = "wasm32"), derive(Arbitrary))]
// Note: the trait bound E: Tag is not necessary in the struct, but it makes the proptest strategy more efficient.
/// A struct representing a scalar pointer with a tag and a value.
///
/// The `SPtr` struct is used to store a tagged scalar pointer, where `E` is its tag, and `F` the field for its values.
/// It has two important aliases, `ScalarPtr` and `ScalarContPtr`, which are used respectively with `ExprTag` and `ContTag`,
/// i.e. the type of expressions and the type of continuations.
pub struct SPtr<E: Tag, F: LurkField>(
    pub E,
    #[cfg_attr(
        not(target_arch = "wasm32"),
        proptest(strategy = "any::<FWrap<F>>().prop_map(|x| x.0)")
    )]
    pub F,
);

Originally posted by @huitseeker in #359 (comment)

[huitseeker]

And the missing piece, ScalarPtr, ScalarContPtr are just aliases:
https://github.com/lurk-lab/lurk-rs/blob/30176c97178c782c54521570f2dcf16846aefddd/src/ptr.rs#L332
https://github.com/lurk-lab/lurk-rs/blob/30176c97178c782c54521570f2dcf16846aefddd/src/ptr.rs#L340

[huitseeker]

Is this closed by #364 @arthurpaulino @johnchandlerburnham ?

[arthurpaulino]

No, but it will probably be closed once the LEM infrastructure takes over the current one

[arthurpaulino]

These will be retired