Fallback to case insensitive searching in some cases

[zackgalbreath]

Perform case insensitive searches for projects and build groups.

The background here is that MySQL performs case insensitive searches by default, while Postgres does not.

Thus, the motivation behind this change is to reduce the impact on our users as CDash instances are being migrated from MySQL to Postgres.

[williamjallen]

While I realize that the case sensitivity change may be disruptive for some users, I think it's worth re-evaluating whether case-insensitivity in these cases provides a meaningful benefit to users in the long run. In the case of filters, there was a clear use case for case-insensitivity, so #2893 certainly makes sense as a feature of CDash. I'm less sure about build group and project names though. These are cases where I think a user could reasonably expect the behavior to be case-sensitive, with mis-capitalizations largely being unintentional.

Handling only these few cases for immediate convenience burdens us with long-term technical debt which is bound to crop up in a multitude of ways in the future. In addition to my primary maintainability concerns, I'm also concerned about security and performance. Treating everything as lowercase means that Postgres cannot use our indexes to speed up queries involving the modified fields in most cases. Additionally, treating everything in a case-insensitive manner means that our unique constraints are effectively useless. In the project name example in this PR, think about what this means for CDash instances where a malicious user creates a project named "project" when an existing project named "PROJECT" exists...

To reiterate, I strongly believe this is not the correct approach to take. Instead, I think we should accept the momentary inconvenience of dealing with breaking changes in a major version release, in exchange for far clearer behavior in the future.