Merge glue module to jsapi

[wusyong]

At the moment, mozjs-sys needs to codegen two different cpp file despite they are all came from the same spider monkey. One for glue module, the other for jsapi. I wonder if we can merge them together and perhaps write some rust implementation instead.

[sagudev]

jsapi is mostly used to collect headers in one place for bindgen to generate bindings, while we use glue to glue some C++ construct that bindgen cannot handle by default (like mozilla::Maybe, class inheritance, ...)

[wusyong]

I understand that, but usually for a binding crate there will only need one codegen. This also causes the confusion on what they do. Maybe we can move them altogether. And for the types that can be handled by bindgen. We will still write C++ construct, but all in one cpp file.

[pewsheen]

Types used in Servo

AppendToIdVector
CallJitGetterOp
CallJitMethodOp
CallJitSetterOp
CallObjectTracer
CallScriptTracer
CallStringTracer
CallValueTracer
CollectServoSizes
CopyJSStructuredCloneData
CreateJobQueue
CreateProxyHandler
CreateRustJSPrincipals
CreateWrapperProxyHandler
DeleteJobQueue
DeleteJSAutoStructuredCloneBuffer
DeleteWrapperProxyHandler
DestroyRustJSPrincipals
DispatchableRun
DumpJSStack
GetLengthOfJSStructuredCloneData
GetProxyHandler
GetProxyHandlerExtra
GetProxyHandlerFamily
GetProxyPrivate
GetProxyReservedSlot
GetRustJSPrincipalsPrivate
GetWindowProxyClass
InitializeMemoryReporter
InvokeGetOwnPropertyDescriptor
IsProxyHandlerFamily
IsWrapper
JobQueueTraps
JS_GetReservedSlot
JSPrincipalsCallbacks
NewJSAutoStructuredCloneBuffer
NewProxyObject
ProxyTraps
RUST_FUNCTION_VALUE_TO_JITINFO
RUST_js_GetErrorMessage
SetBuildId
SetProxyPrivate
SetProxyReservedSlo
SetProxyReservedSlot
StreamConsumerConsumeChunk
StreamConsumerNoteResponseURLs
StreamConsumerStreamEnd
StreamConsumerStreamError
UncheckedUnwrapObject
UnwrapObjectDynamic
UnwrapObjectStatic
WriteBytesToJSStructuredCloneData

[sagudev]

I understand that, but usually for a binding crate there will only need one codegen. This also causes the confusion on what they do. Maybe we can move them altogether. And for the types that can be handled by bindgen. We will still write C++ construct, but all in one cpp file.

Yeah, it really thin line between the two, so I would not oposse merging them in one file, especially because this will give compilation speed benefits (and build.rs simplification).

[wusyong]

We can try a few types first and if everything is fine, we can move lots of them in the same PR.