Investigate the way contracts are inherited on overrides and their associated diagnostics

[JAChapmanII]

Spawned by a comment about search.c/check_final_overrider when contracts are copied from an overridee to an overrider that does not have its own contract list:

      remap_overrider_contracts (overrider, basefn);
      remap_overrider_contracts (DECL_PRE_FN (overrider), DECL_PRE_FN (basefn));
      remap_overrider_contracts (DECL_POST_FN (overrider), DECL_POST_FN (basefn));

Do we (still) need to do it this way? Can we just do the initial remap and then regenerate DECL_PRE_FN and DECL_POST_FN instead, or leave the overrider alone? The basefn's contracts are parsed in terms of their pre/post fn arguments and we definitely don't want to accidentally reinterpret contracts in the context of the overrider.

Shortly before that we have a comment:

      /* FIXME this results in an almost exact duplicate of the final pre/post
	 fns, with just the name of the caller changing. It may be beneficial
	 to collapse these ourselves.  */

can we somehow reuse the existing functions and skip this entirely? Do runtime diagnostics of contract conditions on virtual functions need identify the actual dynamic type when the contracts are inherited? How bad would it be if the line numbers etc point to where the contracts actually appear in source?