Expand functionality of map macro (polyDB)

[alexej-jordan]

as of now, @map can only be called without any arguments to make it work. to enable the user to state what is needed (and thus reduce unneccessary procession of data), i already wrote some code in the already merged pull request for the polyDB access. to give an overview of this issue:

1. the name of the desired fields should be given as the arguments
2. this list is then extended by the field names which are neccessary for an object of the type contained in the collection to be valid. theoretically we can split this up into three parts:
   a) fields needed for the object to be mathematically valid
   b) fields needed for the object to be computationally valid (i.e. in context of the software)
   c) fields we want to be mandatory, e.g. the _polyDB attachment
3. the field names are converted into the right format for projection and handed to the optional opts setting of the find method

due to the way Polymake works, i assume that 2a and 2b are the same, or are there any exceptions i should be aware of? are these the mandatory fields the get_fields(::Collection) method returns in the usual case?
and regarding 2c, i would of course like to know what other fields we want. i assume, only attachments fall under this category, and they all seem important (but the infromation of _id is also contained within _polyDB). do we always have _id, _polyDB and _type?

[benlorenz]

We should preserve _ns and _attrs as well. These five _* elements (_id, _polyDB, _type, _ns, _attrs) should always be present, otherwise the json-object parsing in polymake might fail.
If the user requests plain BSON instead of a polymake object these could be dropped as well.

Apart from the above we should not try to check / enforce anything, it is the users duty to supply a reasonable list of properties here (as when creating an object directly). Most subsets of properties should define a valid object (it might be a different one or just a big class of objects instead). There may be special cases where some inconsistency / problems can appear, in some of these cases the initial rules of polymake will complain but in other cases this will silently be accepted.