Remove Constants class, remove LINQ attributes from models, get things compiling

- This is broken right now (it compiles, but won't run), I just wanted to start getting things into a base state we can figure a schema out from
- Constants is for something that's a RavenDB convention (i.e. keys are CollectionName/{0}/...), so remove it
- Since we're going to be redoing the schema, strip all the LINQ attributes from the entities
- Removed the ClaimId property from CassandraUserClaim and the Id property from CassandraUserLogin because we don't use them/need them
- Have CassandraUser just use the UserName as the Id (temporarily)
Start working on a new schema that implements the bare minimum needed for Identity support

- This doesn't compile yet because of the legacy code
- Commented out the other interfaces that we'll be bringing back one-by-one, implement just the IUserStore<TUser, TKey> interface in this commit
- Create a CassandraUser<TKey> class that only has the bare minimum properties necessary
- Denormalize users on write so they can be looked up by both Id and UserName
- Add a reference CQL script for the schema we're working with
Update the IUserLoginStore<TUser> implementation and add tables necessary to store logins

- Denormalize on write again so we can lookup both by user id and by login provider
- Use compound primary key for logins by provider
- Also update id to userid when referring to a user id just to be consistent across tables
Update the IUserClaimStore<TUser, TKey> implementation

- Only a single table here, so this should be pretty straightforward
Remove custom TUser implementation

- Since we don't really have a good way to persist extra attributes for a custom TUser class (yet), let's remove the TUser parameter from the store and instead just focus on supporting CassandraUser (which we also remove the TKey parameter from and just use a Guid by default for now)
Remove IQueryable support

- We'll *probably* never expose users via IQueryable since C* doesn't support ad-hoc querying, so just remove that interface/property
Add IUserPasswordStore<T> support

- Store the password hash with the user data, so add column to schema
- For now, let's not expose the extra properties outside of what IUser<T> forces us to, so make the new property on CassandraUser internal
- We now need to support UpdateAsync, so add statements for those to update both user tables
Add back IUserSecurityStampStore<T> support

- Same as last commit, keep properties internal for now, store on user object, write them on create/update to both user tables
Add back support for IUserTwoFactorStore<T>

- Same as previous commits, add property to use (keep internal for now), write to both user tables on create/update
Add back IUserLockoutStore<T> support

- Same as previous commits, add columns to table, keep properties internal for now, make sure to update both user tables on CREATE/UPDATE
Add back support for IUserPhoneNumberStore<T>

- Same as previous commits, add columns, keep properties on user internal for now, make sure to update both user tables on CREATE/UPDATE
Add back partial support for IUserEmailStore<T>

- Same as previous commits, add new columns to table, keep properties on CassandaUser internal for now, write to both user tables on CREATE/UPDATE
- This doesn't implement FindByEmailAsync yet, going to require another users table of some kind
Add change tracking for email address and username on CassandraUser
Support usernames potentially changing

- Use the change tracking in the CassandraUser class for usernames to determine what to do to the users_by_username table on Create/Update/Delete
Implement FindByEmailAsync

- Add another table and modify the user data in the users_by_email table on create/update/delete
- Use the change tracking for email in CassandraUser to determine what to do
Don't dispose of the ISession instance by default

- Since ISession is a pretty heavyweight object that has a Singleton-like lifestyle, we probably don't want to take on the burden of disposing it
- Allow consumer to specify in constructor but default to false
Delete some of the unused entities (going to need to find a way to create the schema)
Since we've really only got two public classes now, just move them out of the nested namespaces in the root
Add schema creation support

- Move the CQL default schema script into the project as an embedded resource
- Do some basic parsing of that script to execute the CQL needed to create the schema
Add a basic CRUD test to the integration tests

- Fix bugs found in the store related to null/empty usernames (and preemptively fix the same bug with null/empty emails)