fix m-type generation for m-types that have the same basename

orogen was so far using the type basename as header filename, which meant
that two types with the same name (but different namespaces) would have
the same m-type filename, for instance:

  base::Wrench
  base::samples::Wrench

would have a m-type generated as base/m_types/Wrench.hpp

This commit switches to the full method name (including namespaces).
typekit.rb: minor fix for regex

the mistake shouldn't harm. but the fix won't hurt either.

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>
typekit.rb: fix comments

- "included_files" _is_ an array, see typekit.rb:934
- the parameter _was_ removed/renamed in 2013

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>
typekit.rb: fix missing typekit-name in "orogen_include"

as mentioned here: https://github.com/orocos-toolchain/orogen/issues/7#issuecomment-52231833

fixed to the best of my knowledge ;-) including the typekit-name in the
added line removes the doubled mention of "ReadOnlyPointer.hpp" for
example.

also renamed the "name" variable to a more precise "ptr_name".
reformulated the comments and renamed one of the "inc" variables to
"or_inc", just for a little bit extra-clarity.

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>
typekit.rb: more explicit syntax

not sure if this is good or bad -- am not a ruby guy. but writing "Hash.new" explicitly is more consistent with the rest of the code.

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>
typekit: add warning for non-existing line in "source_file_line"

general muttering: these kind of checks... i don't get it... if the ":"
is missing in the "source_file_line", the API-agreement is broken by
someone. which is a crystal-clear error! orogen should bail out.  I
don't know about the quality concerning the "source_file_line" feature
when backed by gccxml though...

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>
NO MERGE typekit: add "source_file_line" property for "ReadOnlyPointer" and "shared_ptr"

this is to bad... hard-coded path for "boost/shared_ptr". this patch is
only a suggestion, I don't know a better way...

why are these two opaques added by orogen, instead of typelib doing
this, using the actual compiler to look up "source_file_line" resides?

I don't like the idea of orogen going and changing installed tlb-files.
This famous image of a can of worms springs into my mind. Makes
packaging the software impossible. Ordering of the build-process? It
obviously "works" but is unmaintainable in the long term.

Signed-off-by: Martin Zenzes <martin.zenzes@dfki.de>