Only ki should remain in ki repo for v2

[rcoreilly]

with the new generator strategy in v2 vs. reflection in v1, and separate enums, goki tools etc repos, can we get rid of all the rest of what is in ki, putting whatever is still needed in separate repos? Thus, ki could have just the Ki & Node code right in the top level and be much simpler looking.

• kigen->ordmap can be put in separate ordmap repo
• SetRobust and all the other reflect stuff used in giv value views (a lot of kit) could be put in a separate repo with a clever name about being reflect helpers etc. how much of this reflection can be replaced with generic functions now?
• ints, etc are no longer needed post-generics / can be replaced appropriately.

to start down this path, only put ki in v2 under goki.dev, and use existing github for all the v1 stuff until we manage to sort it all out..

[rcoreilly]

lazer is a perhaps overly clever name for the reflect stuff: lasers are based on two mirrors reflecting light back and forth, so they are like "extra reflection", and the lazer spelling connotes "lazy" which is also consistent with the late, runtime nature of reflection processing (vs. compiled).

[rcoreilly]

• laser instead of lazer is Kai's pref. This is used extensively in giv ValueView -- that is what reflection is meant for: arbitrary access to random structs etc.

To get rid of other kit dependencies in ki, we either do without or make a generator so that any high-frequency ki functionality does not depend on reflect.

• make a new embed repo that has embedgen generator to automatically create a map from type name to any interface (with option to specify the base interface type name -- e.g., ki.Ki) for all embedded struct types -- uses that to impl func Embed(tpNm string) (any, bool) method for type, and defines Embedder interface with this method. This will be significantly faster than the current reflection-based ki.Embed method.

• already planning to remove KiFields Remove support for automatic Ki field children #17

• GenCopyFieldsFrom -- move to laser and don't rely on it in gi -- if really needed, make a generator

• TypeAndNameList moves into ki to support ConfigChildren

• TypeProps -- probably not general purpose enough to warrant a separate repo -- just add to goki tools generator to generate a method that returns it for any type that has a corresponding TypeNameProps ki.Props defined in the same package scope.

[rcoreilly]

all done