Extend the clipboard API part two: Setting the clipboard contents

[psychon]

I will pretend that #492 is about getting the selection and watching it change. Now, apparently @Elv13 also wants to set the clipboard's content. This issue is about that part.

Some complications that are required:

• Actually acquiring selection ownership can fail (see ICCCM § 2.1)
• INCR transfers (= large pieces of data have to be transferred in incremental chunks; most of this should be abstracted away by the C code)
• MULTIPLE target (= for efficiency reasons (???), it is possible to request multiple targets at once; I hope I can abstract this away in the C code, but it will be ugly and impossible to test, because even though this is required to be supported, nothing actually uses it)

Some complications that someone might ask for, some day:

• Be able to "give up" selection ownership
• Work fine with external clipboard managers? This means that SAVE_TARGETS might be needed when a selection is given up
• Should it be possible to abort current transfers? E.g. for timeouts?

Is anything from the list above required now?

The "real meat":

• How should transfers be done? Multiple transfers can be active at the same time etc
• Requests can be rejected

---

First attempt at an API:

local o = selection_acquire("CLIPBOARD") -- Either returns an object, or nil if acquiring fails
o:connect_signal("request", function(o, target, t) -- t is a "selection transfer" for this specific request
  if target == "TARGETS" then
    t:send{ data = { "TARGETS", "UTF8_STRING" }, format = "atom" } -- Send an ATOM list
    return
  end
  if target ~= "UTF8_STRING" then
    -- Do nothing here to reject the request
  elseif math.random(2) == 1
    -- Do an incremental transfer
    -- continue is either true (to just indicate an incremental transfer) or a lower bound on the length of the answer
    t:send{ data = "This is the ", continue = 10 }
    t:connect_signal("continue", function(t)
      t:send{ data = "response", continue = false } -- indicate this is the end of the transfer
    end
  else
    -- Just answer directly
    t:send{ data = "This is the response" }
  end
end)

Edit: What aborted transfers (e.g. because the "other end" destroys the window used for the transfer)? Am I free to ignore this for now and to live with the leak, or should this be handled property and we need an aborted signal on transfer objects?