Unify storage and computation type representation by replacing Property with Value

[liulx20]

The codebase currently uses two separate type representations for graph property data: neug::Property (storage layer) and neug::execution::Value (computation/execution layer). This dual representation leads to:

• Unnecessary conversion overhead between property_to_value() / value_to_property() at layer boundaries
• Increased code complexity and maintenance burden
• Potential bugs from inconsistent type handling across layers
• Confusing developer experience when the same logical data has different types depending on context

Performance

SF300

query	property(us)	value(us)	diff(%)
LdbcQuery1	34191.76	33781.83	-1.20%
LdbcQuery2	2343.46	2313.6	-1.27%
LdbcQuery3	69919.12	66775.6	-4.50%
LdbcQuery4	4243.92	4154.21	-2.11%
LdbcQuery5	319849.4	302348.74	-5.47%
LdbcQuery6	6487.67	6452.62	-0.54%
LdbcQuery7	573.22	638.45	11.38%
LdbcQuery8	411.88	475.99	15.57%
LdbcQuery9	251754.88	257710.43	2.37%
LdbcQuery10	33456.36	32802.92	-1.95%
LdbcQuery11	997.33	1047.7	5.05%
LdbcQuery12	6991.42	6939.23	-0.75%
LdbcQuery13	1872.3	1763.05	-5.83%
LdbcQuery14	97637.56	102925.66	5.42%
LdbcShortQuery1PersonProfile	352.73	416.68	18.13%
LdbcShortQuery2PersonPosts	594.75	656.27	10.34%
LdbcShortQuery3PersonFriends	1059.81	1134.04	7.00%
LdbcShortQuery4MessageContent	331.58	395.58	19.30%
LdbcShortQuery5MessageCreator	326.44	391.62	19.97%
LdbcShortQuery6MessageForum	350.46	416.22	18.76%
LdbcShortQuery7MessageReplies	405.72	470.38	15.94%
LdbcUpdate1AddPerson	879.65	1006.46	14.42%
LdbcUpdate2AddPostLike	499.9	586.79	17.38%
LdbcUpdate3AddCommentLike	499.39	585.74	17.29%
LdbcUpdate4AddForum	556.39	643.77	15.71%
LdbcUpdate5AddForumMembership	495.64	580.95	17.21%
LdbcUpdate6AddPost	613.13	711.74	16.08%
LdbcUpdate7AddComment	631.64	729.74	15.53%
LdbcUpdate8AddFriendship	501.4	584.98	16.67%

metric	property	value	diff(%)
throughput(ops/s)	110796.11	109788.56	-0.91%