Rework the way how "specialize" is handled. Instead of initializing the specialization of a full type declaration (including unit name and parent types) it is now considered part of the specialized type itself. This means that for example the following code:

type
  TTestLongInt = specialize SomeOtherUnit.TTest<LongInt>;

will now have to read as

type
  TTestLongInt = SomeOtherUnit.specialize TTest<LongInt>;

While this is not backwards compatible this situation should arise seldomly enough and the benefits especially in context with generic functions/procedures/methods outway the drawbacks.

pbase.pas:
  * try_consume_unitsym: add a allow_specialize parameter that allows to parse "specialize" in front of a non-unit symbol; whether it was a specialization or not is reported using a new is_specialize parameter
  + add a new overload try_consume_unitsym_no_specialize that calls try_consume_unit sym with allow_specialize=false and a dummy is_specialize parameter
  * switch calls to try_consume_unitsym to try_consume_unitsym_no_specialize
pstatmnt.pas, try_statement:
  * switch call to try_consume_unitsym to try_consume_unitsym_no_specialize
  * adjust call to parse_nested_types
ptype.pas:
  + extend id_type with the possibility to disallow unit symbols (needed if a specialize was already parsed) and to report whether a specialize was parsed
  + extend parse_nested_types with the possibility to tell it whether specializations are allowed
  * have parse_nested_types specialize generic defs if one is encountered and local type defs are allowed
  * id_type: only allow "unitsym.specialize sym" or "specialize sym", but not "specialize unitsym.sym"
  * single_type: correctly handle specializations with "specialize" keyword
  * read_named_type.expr_type: there is no longer a need to check for "specialize" keyword
pexpr.pas:
  + new function handle_specialize_inline_specialization which tries to specialize a type symbol
  * handle_factor_typenode: handle specializations after a point that follows a record or object (why isn't this part of postfixoperators anyway? O.o)
  * postfixoperators: handle "specialize" after records and objectdefs
  * factor_read_id: handle "specialize" in front of an identifier (and after unit symbols)

+ added tests
* adjusted test webtbs/tw16090.pp

git-svn-id: trunk@29768 -