Modified ScriptDB to use a custom bcp Unicode character format.

 * Tables with 50,000+ rows still use Unicode native format (these are treated as raw files).
 * Smaller tables use the custom Unicode character format. These data files can be viewed, diff'd, and merged as utf-16 text files. This improves performance over a bunch of INSERT statements without locking the data away in a binary .dat file that is unfriendly for source control. To distinguish these files from binary .dat, I'm using a .udat extension. This will allow us to configure text editors to open .udat files and configure git to diff and merge them (we couldn't do that if we used the same extension as binary .dat files).
Modified ScriptDB to use other custom BCP formats.

 * For tables with 50,000+ rows a compact CSV-like format is used (it isn't actually CSV because I wanted to use a multi-character delimiter that is unlikely to occur in our static data). Since this is a text format it can be viewed, diff'd and merged whereas the binary .dat format cannot. The full JSON-like format is too verbose for tables with a large number of rows, resulting in files that are too large.
 * For tables with less than 50,000 rows we use a JSON-like format that is even better for viewing, diff'ing and merging.
 * Both formats are saved as .txt files using the Windows 1252 code page. We could make text editors and source control work with the utf-16 format, but that may lead to more issues. The old approach using INSERT statements used text files with Windows 1252 so we've already been working fine without Unicode support.
Fixed issue scripting data for tables with sql_variant columns.

The new text-based bcp data file formats don't correctly handle sql_variant columns (when you create the database from scripts the values will all be varchar instead of preserving the correct type). So when the table contains a sql_variant column I fall back on the method that uses INSERT statements (for smaller tables) or Unicode native (binary) format for larger tables.
Added support for scripting read-only databases.

 * If the database already exists, SET READ_WRITE at the start of the script.
 * Removed the SET READ_ONLY statement from the Database.sql file so that objects can be added to the database.
 * Add SET READ_ONLY to the end of CreateDatabaseObjects.sql.
Include extended properties in scripts.

All we really care about is the description ('MS_Description') extended property so that we can use database documentation tools (e.g. http://www.livedoco.com/). If our scripts begin to get cluttered with non-documentation extended properties we may want to consider how to only include the description extended properties.

I added the ExtendedProperties option to the ScriptingOptions objects used to script things out. I set the property for all types of database objects even though some of these objects may not even support extended properties.

I also ran into an issue when scripting tables since tables are actually scripted as multiple files. The extended properties of the table and columns were included in each file (the additional files are for keys, constraints, indexes, and foreign keys). To avoid these duplicates I added a HashSet that keeps track of the unique "EXEC sys.sp_addextendedproperty" and then skip writing it to the file if it is already in the set.
Added support for scripting database diagrams.

Now the dbo.sysdiagrams table is scripted out if it has any rows (diagrams).