The Framebuffer object is not actually a buffer, but an aggregator object that contains one or more attachments, which by their turn, are the actual buffers. You can understand the Framebuffer as C structure where every member is a pointer to a buffer. Without any attachment, a Framebuffer object has very low footprint.
Now each buffer attached to a Framebuffer can be a Renderbuffer or a texture.
The Renderbuffer is an actual buffer (an array of bytes, or integers, or pixels). The Renderbuffer stores pixel values in native format, so it's optimized for offscreen rendering. In other words, drawing to a Renderbuffer can be much faster than drawing to a texture. The drawback is that pixels uses a native, implementation-dependent format, so that reading from a Renderbuffer is much harder than reading from a texture. Nevertheless, once a Renderbuffer has been painted, one can copy its content directly to screen (or to other Renderbuffer, I guess), very quickly using pixel transfer operations. This means that a Renderbuffer can be used to efficiently implement the double buffer pattern that you mentioned.
Renderbuffers are a relatively new concept. Before them, a Framebuffer was used to render to a texture, which can be slower because a texture uses a standard format. It is still possible to render to a texture, and that's quite useful when one needs to perform multiple passes over each pixel to build a scene, or to draw a scene on a surface of another scene!
The OpenGL wiki has this page that shows more details and links.
It is not possible to share framebuffers between different contexts. See the first paragraph of Appendix D, OpenGL 3.3 spec. However, you can share textures and renderbuffers, which should give you want you need.
As for the threading: It should be possible, but it is generally advised not to issue GL commands from multiple threads (Because it is just very hard to synchronize). Usually, you would copy the contents to a pixel-buffer-object and and map it from the GL thread, then use the mapped pointer from the other thread.
Best Answer
You can, if the two FBO were created in 2 different context.
However, compositing them together on screen in one window will require passing them back to software and then back to hardware in the window's context. This will be slower than just rendering them both in the main context on one thread.
You're better off focusing on getting the rendering into a single thread if it's going to be in one window, and putting your focus on threading elsewhere. Culling and physics are great places to thread (if you have those), but for rendering, one thread per context is the basic rule of thumb (and each window will pretty much mean one context).