Planned SM6 Refactorings

There are some things that I want to pull off for SM6, but I don't know of the chances.

[ulist][*]C++11: Modern language.
[*]Dropping of VS2010 and below: similar to above.
[*]Removal of many ASSERTs: our code should be more robust.
[*]Better handling of singletons: they are too pervasive.
[*]Removal of RStrings: std::string should be plenty now, and I believe the original StdString has a lot of items that are mainly for supporting environments we no longer support.
[*]Different LUA library: would prefer to have something that doesn't require lua_State in our code objects.
[*]New class: Translit class. It would contain two string variables: actual name and transliterated name.
[*]New classes for Music Preview. Base class would define the bare minimum for playing the demo music: implementing classes would deal with either multiple times or separate files or something.

More to come later.

C++11: With compiler-specific extensions. We use a lot of the GNU stuff that probably won't ever have a standard equivalent. We can continue doing the preprocessor-macro dance we've always done to keep the different compilers and variations in check.

VS: My plan for SM6 is that VS as a whole won't have official standing at all but we're not gonna ban it or anything either. It will be an "at the developers' whims and conveniences" thing -- those that use it are free to maintain the project files, but if they break, they break, it's the onus of whoever wants to use VS to figure out why. If someone wants to use VS2010 for their own stuff, we'll leave projectfiles there in whatever state they happen to be in. Good luck.

---

Asserts: Eh, asserts do make things more robust if you use them right. That said the assert situation overall needs a lot of cleanup. We should deprecate ASSERT() / ASSERT_M() / DEBUG_etc in favor of something more forgiving. What I'm thinking is:

ASSERT_DIE(): If this condition is true it will 100% absolutely every time crash the game outright or render it completely unusable (i.e. deadlock or massive memory corruption) or has a high chance of corrupting nonvolatile data (user profiles, songs, etc). Die now so at least we know what happened. **If you're using this one, you should have a DAMN good reason.**

ASSERT_WARN(): If this condition is true the resulting behavior is very unlikely to be what we wanted. It MAY crash or corrupt data but it's not an almost certainty. Generate a crashinfo.txt, notify the user that Something Bad happened, and produce a SIGTRAP in debug mode, but keep running.

ASSERT_DEBUG(): This condition should not be true but there may not be any ill effects at all. In debug mode, treat as ASSERT_WARN; otherwise just dummy it out entirely. (Debug mode would become the default to keep this bastard in check.)

---

Lua: Alternately just make our own wrappers/macros. It may be less work. I do agree that the current syntax is incredibly obtuse and hard-to-read.

Contribute some of my own:

arch: rename to "drivers". Move anything that hits an external API (with the singular exception of the C++ STL) here. Meaning RageSurface_Load_*, RageSurface_Save_*, RageDisplay_OpenGL/GLES2, RageSoundReader_*... you get the picture... most of archutils/, and so on will instead live here and be integrated with the driver selection infrastructure.

The RageFile stuff needs some way to communicate to its callers when a file is not yet available but will be soon, such as it's still being downloaded in the background. This info should be propagated all the way back up to the theme itself so it can tell the user that the data is there but it's not ready yet.