add support for EVAL[SHA]_RO via new CommandFlags.ReadOnly

[mgravell]

[NickCraver]

For call today: note this interacts a bit with #2191, but I'm thinking this is a bit odd in a top level view at least with how other commands currently behave: "use read-only if we can" internally - should chat on how we want this to look at the top level and maybe apply to SORT_RO the same? It's an odd case, but wonder if we can handle one way - doing this at the server selection phase maybe does make more sense overall rather than adding more commands for sure.

[slorello89]

@NickCraver - worth noting that eval/evalsha is a weird case. Unless you want to add a lot of intelligence to the lua parser in the library, there's not going to be a good way to know ahead of time whether or not the command is in fact RO, so abstracting it from the user is impractical. In the case of SORT vs SORT_RO, for example, we know if it's going to be readonly or not based on the presence of a destination key.

My two cents on this, I kinda think this might be the case where you might want to either add new EvalRO & EvalShaRO methods to IDatabase OR add a read-only setting to the LuaScript class and use that to determine whether it would be readonly or not. Personally, I think I'd lean towards the latter. The extra command flag might get confusing, especially if it doesn't end up getting applied consistently.

[NickCraver]

Since we ended up going the #2168 route - cleaning up!