No longer add dynamic property for alias, simply rely on
get(Dynamic)PropertyByName() to check for aliases.

Add new API PropertyContainer::getPropertyNamedList() so that
ExpressionCompleter can discover properties with aliases.

The previous syntax for sub-object referencing is kind of awkward, but
is unambiguious nevertherless.

The new syntax allows referencing sub-object like,

    Part.Origin.X_Axis

which may be ambiguious in case there is also a (existing or future
added dynamic) property named 'Origin'. The expression parser will
automatically convert this more natural syntax to the unambiguous one
like,

    Part.<<Origin.X_Axis.>>

The new syntax works for label reference as well,

    <<Part>>.<<Part001>>.<<Cube>>

which will be converted to
    <<Part>>.<<$Part001.$Cube.>>

Make use of the more user friendly sub-object referecing syntax.

Refectored ExpressionCompleterModel to support completing Python
attributes, using CallTipsList::extractTips().

Since ExpressionCompleter will now look into Python attributes, there
is no need to expose duplicated information through getPaths(), except
those that provides extra information (e.g. Rotation.Angle with extra
unit information)

getPyPathValue() is modified to return Python attributes after the
given path.

The Python exception is supposed to be captured by application code. If
it is somehow leaked, it may cause system instability.

Before this patch, the definitions of unit are somewhat duplicated in
several places, Base/QuantityParser.l, App/ExpressionParser.l,
Base/Quantity.cpp, App/FreeCADInit.py, etc.

This patch remove all duplications (that I can found), and put them all
inside function Base::Quantity::unitInfo(). Here is how other code
obtain the definition,

Base/QuantityParser.l calls Quantity::fromUnitString() and resolved the
unit at parsing time.

App/ExpressionParser.l treats unit token as IDENTIFIER, and let the
expression parser (ExpressionParser.y) to decide whether to resolve the
unit at parsing time (by calling UnitExpression::create()), and create
a VariableExpression and resolve the unit at runtime (if there is no
property found with the same name).

App/FreeCADUnit.py expose Python predefined units using
App.Units.listPredefinedUnits/listUnitTypes(), which are implemented in
UnitsApiPy.cpp.

The benifit of moving unit token parsing out of expression lexical
scanner is that we can safely introduce new unit keyword without any
risking of breaking backward compatibility. Because the lexical scanner
will not mistakenly treat any identifier in existing expression as unit
because of name clash. In does introduce some side effect as the unit
may or may not be resolved at parsing time. For example, an expression
'1m/s' may be evaluated to different results depending on whether there
is a property named 's'. To avoid this, the user can opt to bracket the
unit expression, like '1(m/s)'.

To return a (sub)object reference that is suitable for assignment to
link type property

This must be the cause of mysterious test failure on Travis!

Because there is now a way to resolve name clash with unit.

Object reference will be auto converted to external or internal
reference depending on whether the referenced object is exported
together or not.

Related FreeCAD#2477

Support old syntax of map indexing for backward compatibility,

    Obj.PropertyMap.<<key>>

For named constraint with space.

Add Quantity::concat() to handle quantity concatenation, which can
either be plus or minus depending on the signedness of the left
quantity.

1m1mm is interpreted as 1m plus 1mm,

-1m1mm means -1m minus 1mm.

-1m-1mm means -1m minus -1mm, i.e. -1m plus 1mm.

(0-1)m-1mm means -1m minus -1mm, i.e. -1m plus 1mm.

That is, to supress 'unexpected end of input' ParserError.

Try to resolve as much information as possible

Support 'MatchContains' on sub-object/property/attribute
Fix sub-object/element references

In case either and new or old name contains space

Because user code may want to silence the exception