CORBA26 — ComponentIR Interface fixes

While reviewing the ComponentIR interfaces in 00-11-01, I have found
some problems with it. (These are unrelated to the current discussion
about the Interface Repository itself.)

Many interfaces inherit Contained::describe(), which is supposed to
return information about the element. In the basic IFR, this data is
designed to contain all possible information about that type. This
is very convenient, since then a map mapping RepositoryIds to
Contained::Description contains all of the IFR's information.

By referring to InterfaceDefs rather than RepositoryIds, the client
will need to store that association elsewhere, or repeatedly invoke
the Interface Repository.

Suggested resolution:

• In ProvidesDescription, replace
  InterfaceDef interface_type
  with
  RepositoryId interface_type

• Ditto for UsesDescription

• In EventDescription, replace
  ValueDef event
  with
  RepositoryId event

• In ComponentDescription, replace
  ProvidesDefSeq provides_interfaces
  UsesDefSeq uses_interfaces
  EmitsDefSeq emits_events
  PublishesDefSeq publishes_events
  ConsumesDefSeq consumes_events
  with
  ProvidesDescriptionSeq provides_interfaces
  UsesDescriptionSeq uses_interfaces
  EmitsDescriptionSeq emits_events
  PublishesDescriptionSeq publishes_events
  ConsumesDescriptionSeq consumes_events

• In PrimaryKeyDescription, replace
  ValueDef primary_key
  with
  RepositoryId primary_key

• In HomeDescription, replace
  PrimaryKeyDef primary_key_def
  FactoryDefSeq factories
  FinderDefSeq finders
  with
  PrimaryKeyDescription primary_key
  OpDescriptionSeq factories
  OpDescriptionSeq finders

Next, all parts of the "basic" Interface Repository are mutable, but
most attributes of the Components interfaces are declared as readonly.
I propose to remove the readonly modifier from

• ProvidesDef::interface_type
• UsesDef::interface_type
• UsesDef::is_multiple
• EventDef::event
• ComponentDef::supported_interfaces
• ComponentDef::base_component
• ComponentDef::provides_interfaces
• ComponentDef::uses_interfaces
• ComponentDef::emits_events
• ComponentDef::publishes_events
• ComponentDef::consumes_events
• PrimaryKeyDef::primary_key
• HomeDef::base_home
• HomeDef::managed_component
• HomeDef::primary_key
• HomeDef::factories
• HomeDef::finders

Last but not least, there seems to be some confusion about Primary Keys.
When a Home is created with Repository::create_home, a ValueDef should
be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
would be a chicken-egg scenario.

Proposed resolution:

• Change the ValueDef in Repository::create_home to PrimaryKeyDef
• Move the create_primary_key() operation from HomeDef to Repository

see below