C++ unparsing extensions

[EraYaN]

These are some of the extension from PR #6 but rebased on current master.

So I added some try catch blocks, because type_comments are not used in some of the ASTs I generate. Not sure what the values of those would need to be.

Also the _Attribute unparser function did not seem to support arbitrary objects. I added a warning, but really this should be supported in a better way. So I can unparse to struct_var.attr and the like.

[mbdevpl]

I'm looking over the commits in this PR - and some of the work is good to merge right now, while other parts need rethinking IMHO.

Also, I just enabled appveyor for this project, and started "windows" branch. So if you wanna experiment with windows support, I'm all in, but let's do this outside of this PR. I'd highly recommend avoiding bloating the PR because it will become really hard to merge...

E.g. setting the log dir on windows is an instant merge, but since it is bundled with all the other changes I just uncommented that line and made another commit right now. And the point about certain key-value pairs being missing from Python config on Windows - I completely can see that the current code will simply fail to import on Windows... But on the other hand I'd like to avoid using ifs there... If anything, I'd probably like to make the classes GppInterface and ClangppInterface try to set their fields to correct values at object init time instead of class init, so that they will fail to instantiate when someone tries to do that on Windows, instead of silently kinda-succeeding but missing some fields later.

And I'd also welcome improved comment/pragma/directive support - currently it's one big hack, but how about a dedicated Directive node? Like Comment node, it would come from horast module - I already did some preliminary implementation there long time ago, but never merged it. I'll do something simple there now, and we can discuss about how to improve it. Maybe Directive node could be something beyond "whatever was there, stored as a string"?

Overall, I think that if you make a list of conceptual changes that you've implemented so far, or want to implement, and start branch in your fork for each, it could go much faster. I actually have my local git set up to also fetch from your fork, so I actually can merge your changes without the whole PR overhead... But on the other hand, PR gives all the CI goodies, so :)

[EraYaN]

Right for the missing python config variables, they are not even guaranteed to be there on *nix platforms. It might be better to get them one by one instead of the array, and fail on those individually. (Also some of them SHOULD be missing, since Windows does not have some of those, or finds them automatically.)

I will split this up when I have some time, but for now I just need a working copy on Windows (Xilinx Vivado HLS is best on Windows).

[EraYaN]

I rebased this, I have yet to check if I broke my other projects, but this should now have the correct horast dependency.