Refactoring species information (Umbrella issue)

As the number of species tracked and the number of organizations tracking species increase, a significant shift in Greenstand species management is needed: organizations should to be able to add to and manage their own ‘local’ species lists, using their own local names and/or scientific names. As time permits, GS botanists can then link local names to a global species list (currently in the `tree_species` table). More details and a modified DB schema are given in this [design document][1]. This issue is an umbrella issue for discussion, which should then generate other issues for specific actions.

Steps involved in the creation of the new data management features include:

**1. Adding new tables to the database** Three new tables are needed: `det` = determination, `localname` = organization-level species names, and `taxonmap` = mapping between local names and global names. Because these are being inserted between `trees` and `tree_species`, it is anticipated that changes to the DB schema can be made without interrupting existing services. A suggested SQL schema for the new DB tables is [here][2].

**2. Modifying the microservices API** Changes needed:

* Serve species names from `localname`, and from `tree_species` where a link from local to global species has been made.
* Write to `localname` for any admin panel user in an organization.
* Write to `det` when a species choice from the `localname` is made for a capture in the admin panel - this information is currently tracked in a JSON structure `audit`, but needs to be stored in a normal table field for efficiency reasons.
* Write to `taxonmap` for an ‘species admin’-level user in the admin panel.
* Writing to `tree_species`, the global names list, must be restricted to ‘species admin’-level users.

**3. Changes to admin panel UI** to use the new microservices. These include:

* Restricting users to only see their organization’s local species, and to assign those species to a capture.
* Allowing users to add to and edit their organization’s local species list.
* Modifying permissions to add a ‘species admin’ level for users.
* Allowing only species admin users to edit the global species list.
* Creating a new UI element to permit mapping of local names to global names, for species admin users. See [ADR][1] for more details of this element.

**4. Downstream changes to Treetracker map** to display local name, and global name if assigned. These should be minor since the app does not write to DB.

**5. Downstream changes to Android and iOS apps** to display local name, and global name if assigned. These should be minor since the apps do not write species info to DB.

**6. Documentation changes**, especially for admin panel users.

Please comment on the overall process here, and start new Issues as needed.

[1]: https://github.com/Greenstand/treetracker-decisions/blob/main/0012-species-data.md
[2]: https://github.com/Greenstand/Tree_Species/blob/master/sql/new_species_info.sql

Start with the linked species-data design document and the proposed SQL schema in new_species_info.sql, then review the listed database, API, admin-panel, downstream, and documentation areas. This is an umbrella issue, so the immediate outcome is a set of specific, independently actionable issues rather than one implementation. Done means the required work has been scoped into follow-up issues with clear ownership and completion criteria.

Written by the indexing model from the issue text.