Fix TODOs for generic structs

[abeln]

This issue tracks the TODOs left during the initial implementation of generic structs (see comments below).

[abeln]

Better error messages for expanding cycles

Once #638 is merged, we'll raise an error when we detect an expanding cycle in a generic struct.

e.g.

struct F _For_any(T) {
  struct F<T> *f1; // allowed
  struct F<struct F<T> > *f2; // error: expanding cycle
};

The error as displayed in #638 is very basic: it only mentions that there's a cycle, but doesn't mention which structs (nodes) are involved in it. We'd like a better error that mentions the involved structs and fields.

e.g.

struct G _For_any(U);

struct F _For_any(T) {
  struct G<struct F<T> > *g;
};

struct G _For_any(T) {
  struct F<t> *f; // error: expanding cycle: G (field f), F(field g)
};

[abeln]

Improve the efficiency of ASTContext::getTypeAppsWithBase.

  /// Return all type applications that have the given generic decl as base.
  /// This is currently slow since it iterates over all cached type applications.
  /// TODO: improve its efficiency.
  std::vector<const RecordDecl *> getTypeAppsWithBase(const RecordDecl *Base);

[abeln]

Handle case where a struct has both a _For_any() and _Itype_for_any() specifiers (ParseDeclCXX.cpp:1650).

  // Checked C - handle generic structs.
  if (Tok.is(tok::kw__For_any)) {
    // TODO: add error handling here.
    unsigned DiagID;
    const char *PrevSpec;
    DS.setSpecForany(Tok.getLocation(), PrevSpec, DiagID);
    ParseForanySpecifier(DS);
  }

[mgrang]

@abeln Has this been fixed? If yes, please go ahead and close this bug.

[abeln]

Nope, these are still open.

[abeln]

Another TODO: handle serialization and deserialization of generic structs.