As suggested by meta-androcto:
http://blenderartists.org/forum/showthread.php?336209-ANT-Landscape-generates-terrain-with-incorrect-normals

Separate all utils and constants definitions into a new export_fbx_bin_utils.py file,
helps (a bit :/) to navigate in insanely big export_fbx_bin.py itself!

FBX export: Huge refactor of 'Model' part of the code, and fix exporting instances when org objects are not selected.

'Model' data (which can be Blender Object, DupliObject or Bone/PoseBone) are now
wrapped in an ObjectWrapper class that present the same API in all cases.
Hopefully this will make that part of the code easier to follow (and maintain/troublefix).

Also made var names a bit more consistent.

Note all this makes export slightly slower in worst cases (many actions to check against objects),
about 15% it seems. But tha 'export all actions' code need some more attention, maybe it's
possible to enhance its performances?

The format is old and each engine seems to have different versions of the spec,
which makes it hard to support well.

FBX export: force to write animcurves even when we could avoid it (only one value [feyframe] in it),
when exporting actions.

Note this is not ideal either, since some non-animated parts might be keyed now... No ideal solution,
but in case of actions, probably this is better than not exporting 'static' actions.

Note only particles/dupliobjects existing in the current frame will be taken into account.

Dev note: the 'object' part of the code becomes really ugly, it will need a serious
refactor (probably using some kind of wrapper around Object/Bone/PoseBone/DupliObject),
nobody (not even me) will be able to follow this code soon.

devide chars by 255, not 256...

Export actually works perfectly well, here (Unity probably just does not supports scale in tex mapping...).
But importer completely ignored texmap data when working with non-nodal materials - we at least can support
offset and scale data here!

That was not really true, since each strip from NLA would be exported as an animstack already.

Supporting 'all actions' feature was in fact a bit hairy, because actions are not
linked to objects in Blender (you can assign any action to any object). Did it this way:

for all exported objects:
    for all actions in bpy.data.actions:
        if action is 100% compatible with object:
            temp assign this action to the object, and bake animation of this object only into an animstack

This does not make great code, but seems to work rather well... Just be sure to not have invalid
paths in your actions! ;)

Rough guess, 2.0 for obj (because of quite heavy changes in it this fall/winter),
and 3.0 for FBX (assuming 1.0 = 6.1 exporter, and 2.0 = 7.x importer, makes 3.0 = 7.4 exporter)

FBX export: do not apply Armature modifiers when we export armature objects, rather than use animation or not!

FBX export: always copy org (blenddata) matrices (when not done implicitely by e.g. multiplication).

Looks like nothing is expected for BindPose nodes here? Anyway, I'd guess those are
doublons with cluster data... :/

Yet another stupid mistake. :/

Normals are not optional for STL so remove the option from the UI.

Clamp branchL to min 0.0 (negative branch length does not make much sense, and
non-int power of negative numbers gives complex numbers...).

This kind of target app compatibility feature is not well suited to an export addon,
would better be in a dedicated pre-export tool.

Was broken since apply modifiers and other geom types support was added.

If new option "Simplify Skinning" is set (by default), only four most significant weights are kept.
Else, only a warning is issued.

Also added more OrederedDict's!

* When exporting actions from NLA, do not export global 'scene' action (unless there is no actions in NLA!).
* Export actions from NLA as all starting from 0.
* Fix take time to be one frame longer than the longest animstack exported.