'Open in Browser' option for files and directories

### How to use GitHub

* Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are interested into the same feature.
* Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
* Subscribe to receive notifications on status change and new comments.

**Is your feature request related to a problem? Please describe.**
- Not natively (by the nextcloud app or any other local app) supported filetypes (like whiteboard or gpx) are downloaded instead of opened in the browser where they could be viewed/edited.
- The nextcloud android app has its limitations in some circumstances, being able to quickly switch to the browser without losing context (current file/directory) would often be helpful.

**Describe the solution you'd like**
An option in the file/directory _options menu_ (three dots) that directly opens the selected file/directory in the browser.

**Describe alternatives you've considered**
- There is already an option to share the _internal share link_ (i.e. the above described link) to any local app but it's hidden in the _options menu_ under _details_ and then _sharing_. Also the browser must then be selected between all apps that support recieving input from other apps.
- Additionally there is an _open in_ option for files (or just tapping the file) but using this on filetypes not supported by any local app just tries to download them (i assume because the filemanager is the default handler for unknown filetypes).

**Additional context**
The backend for creating a link that could be opened in a browser seems already implemented.
The function to open the link directly in the default browser is also already implemented but not used/placed in a user-friendly way.

Adapting _open with_ to let the user choose
- browser (internal share link opened with default browser)
- another app (filecontents/path to another app)
could also solve this.

Additionally (at least to me) the behaviour of saving an unknown filetype using the filemanager app when selecting _open with_ and not _export_ is unwanted. Isn't that exactly what _export_ is for? If it can even be prevented is another question.

Generally I feel like the sharing options are misplaced in the _details_ view (maybe a dedicated _share_ option in the _options menu_) and the _details_ view breaks with other ui-concepts in the app but that's another topic.