[nem-en] Multiple project solutions

[vc]

> BTW. I don't quite understand why do you accept top level "attribute"
> macros generating code, but don't accept expression level ones.

Top level attributes (meta-attributes) parse and execute during we make
"type tree" (NamespaceTree). NamespaceTree rebuild any time if tope level
AST changed.

Opposite, expression parse lazy (on demend). We chase Locations and read
actual code from source. 
See line 455 in ncc\hierarchy\ClassMembers.n and below.

It's incremental compilation code. 

> Those
> two uses cause similar problems:
> when VS must re-parse the project, then generated classes may be
> cleared (and then engine would have to somehow know which macros
> execute again) or if they are not cleared, then they might cause
> duplication errors during second execution

Aha. And it nudge our to reparse all sources if top level AST changed.
At begin I try optimize and cache TopDeclarations, but this cause class
duplication. 

> As for the places, which depend on code generated by expression level
> macros, I wouldn't care much about it - even now we don't (and we
> can't) guarantee order of compiling types / methods, so such code can
> break anyways. So I think that the valid uses of expression level code
> generation are of two kinds:
> - macros are generating classes / methods / fields, which are used
> just after their execution in the same methods, where they were
> invoked
> - macros are generating code as a side effect only (so this code is
> not used anywhere in the project)

What about [Record], [Accessor] and so on?
At now macro-attributes do not cause problems.
Problems appear only if expression-macros cause side affect (and other code
try to use code generited by it).

> The second one can cause similar problems as we discussed for using
> macros - if you cannot ensure that all methods were processed, the
> only way to make generated code visible is to generate compiled
> binary... I guess this is a rare case, but it can happen and I think
> we can accept such workings - usually if such situation exists then it
> is for "generated stuff" assembly, which is dedicated as holder of
> automatically generated code and user will try to keep it compiled
> most of the time. For me it is natural, that if I do heavy code
> generation, then I will always "pre-generate" the target library when
> I need and then use it in other projects.

Once again. No problem with top level macro. Even if it is a parameter
macro-attribute (like [NotNull] macro). But expressing level macro cause big
pain in... 

And very strange when functional language encourages side affect in
expressions.

If we allow side affect in expressing level macro we must maximally isolate
it. And we must warn users about possible problems.

In my option, possible problems don't to be worthy of it.