Note this needs testing still, not quite sure the result is correct yet (though it looks correct),
as usual with FBX (FBX Converter at least does not seems to read embedded textures). :/

Will disable this option before release, if I can't make it work till then.

Fix T40216: Binary FBX exporter doesn't export proper materials to Unity when there's a modifier added.

This is not a bug, in fact, but imho we do not need to compare exactness of values
up to the 6th decimal, 4th decimal should be enough, and will avoid such cases of
"over generation" of data...

Export: generate a valid scale value from Blender scene's Scale setting (if valid, else 1.0),
assuming 1BU = 1m and 1FBX unit = 1cm.

Import:
* Use by default axes and scale data in FBX file instead of manually specified ones (using same
conventions as in exporter).
* Also import FPS data from FBX file (crucial for future animations import!).

And a few fixes for issues found in those areas as well...

Rename export_fbx_bin_utils to fbx_utils, since some of its content will be used by importer as well.

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... :/