[Gtkradiant] Str and string_t

[SmallPileofGibs]

This addresses http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=815
I wrote string_t a while ago for use in my own projects which use stl
heavily. Below are the reasons for including it in radiant..


Issues with Str

- dependencies
printf method is bloat, either requires glib or is limited to 1024 chars (with no buffer-overrun check)

- bloated public interface not documented and non-standard (inherited from MFC CString?)
TrimLeft, TrimRight, Left, Right?
algorithms like Find can be implemented with iterators and non-member functions
does not provide useful STL stuff like a constructor to create a string from a range of chars

- questionable implementation
written procedurally (everything in one function), not functionally (private helper methods to do common stuff), causing unnecessary duplicated code
m_bIgnoreCase can be pushed outside the class
g_pStrWork is completely pointless


Issues with string_t

- name does not obey coding convention
- should not be in qertypes.h


Good things about string_t

- provides interface compatible with std::string (ie. code that uses string_t can use typedef std::string string_t)
- completely STL-container-safe (ie. can be copied safely)
- functionality is clearly limited to preserve performance (ie. does not provide operator+=)
- clean, simple, functional-style implementation


Conclusion

string_t provides a very simple implementation of part of std::string's interface, it does not replace Str.
string_t and Str should both be cleaned up and grouped in the same library, so they can share parts of their implementation.