Revert decision to use Map[String, Any] as map implementation.

 - Problem is we cannot guarantee JSON serialization for type Any resulting
   in compiler errors.
 - It is annoying to use something like Map[String, JsValue]...
 - Go back to Map[String, String] -> it is the responsibility of the caller
   when using maps to serialize to/from string.
 - This has the nice benefit of discouraging use of Map which is one of our
   goals with Apidoc (well defined APIs should have typed records, not maps),
   reserving the use of maps to where they make APIs more natural (e.g. true
   key value store APIs like Tags)
 - Acknowledge that this is a subpar implementation - there will be APIs we
   cannot support with this decision - but we expect those to be rare. In
   most cases we expect to be able to support APIs by defining more concrete
   model types.
 - In practice, this is a nice incentive for API designer as maps have the risk
   of making API less predictable to use.
Update routes/controllers from String guids to UUID
Add user authentication resource
Remove openid and add a login form
Remove User upsert - expose create directly. Capture password in create
Store password on registration in proper hash
Add tests to make sure a newly created user can login
Drop users.image_url
Fetch all user roles
Add wrapper to explore org level authentication
Switch to AuthenticatedOrg
Implement user workflow to request permission to join an org
List admins and display information when there is
no admin to review a membership request
Remove debugging
Add password for root admin account
Add test to ensure that user is admin of an org created
Experiment with passing actual user guid along as a header in API call
Update versions PUT
Use generated client to upload Versions
Fully remove original hand written client