Inefficiencies around MobileSettings handling

In adding the TimeZoneAbbrv field to the MobileSettings process, I noticed a few inefficiencies and also talked to Cherlyn about a couple potential problem areas we should try to fix \ regression test:

1) As part of the "GetExtraProperties" process in the UserRepository as we validate the MobileSettings I noticed that if we are generating them for the first time, we are not writing them back to the database. The only time we actually cache these to the database is when you do a "ChangeStore" through the UI. This means that all of the users we have that only have access to a single store (which is most of them) will never cache this data and will generate it from scratch on every request. This is probably not a HUGE database hit, but it seems like something easy to skip over and ensure that this part of the code works the same whether you have access to only one store or many.

2) We are actually caching the "Configurations" list to the database even though we are overwriting it every time we pull from the database. We need to do one of 2 things: a) the simple approach is to exclude "Configurations" from the data we are writing to the DB (I think a simple "[Ignore]" directive would work or possibly a custom NHibernate mapping definition, or b) see if we can cache this to the DB on initial Login and then just use that cache rather than pulling from the DB as often (we would still need to reload Configurations on a "ChangeStore" as they are Entity-specific)

3) Cherlyn pointed out an ongoing bug that should be fixed: If someone is removed from a store but that store is still in their cached "MobileSettings" we will allow them to log into it by default. Once they switch to another store they cannot get back, but until then they would have access. This can we fixed by validating the MobileSettings.Entity ID against the list of UserStores we are already pulling. In this case, we should re-pull the MobileSettings as if we did not have one at all.

4) Another concern from Cherlyn was around the MMS SSO. We need to test and be sure that when you SSO into Mobile that you land on the right store as defined from your MMS context (Orders, Workflow, etc.). This has caused problems in the past and may be one reason this caching we want to do in #1 above may have been purposefully removed.

5) We may want to research as well a process to Refresh the MobileSettings cache on every login (definitely manual, possibly SSOs as well). This would give us some cover around stale cached data. Even though store names and time zones will not be changing, it might be good to refresh occasionally.