Fix database migrations to support non-augur database usernames

[PredictiveManish]

Description

• Fixed two locations where OWNER TO "augur" was hardcoded:
• 0_legacy.py: Added dynamic replacement of OWNER TO "augur" with OWNER TO CURRENT_USER before executing legacy SQL migration files
• 3_oauth_and_user_groups.py: Changed hardcoded OWNER TO "augur" to OWNER TO CURRENT_USER in the user_groups table creation SQL

Technical Details

• Uses PostgreSQL's CURRENT_USER keyword which always resolves to the current database session user
• Handles all variations: OWNER TO "augur", OWNER TO 'augur', OWNER TO augur
• No database queries needed - uses PostgreSQL's built-in functionality
• Works with any database username without code changes
• Solves Database initialization (via alembic) assumes a user called "augur" is present #3417

This PR fixes #3417

Notes for Reviewers

Signed commits

• Yes, I signed my commits.

[MoralCode]

unfortunately, I don't think retroactively changing the migrations is the answer here. My ultimate hope is that, once #3435 is good to merge, we can switch the database initialization over to a different method that doesnt require replaying migrations from very old versions of augur

[MoralCode]

Closing this PR since the only changes it makes are to old migrations that should not be changed (because they are how older instances get themselves up to date with the latest augur versions.