Update composer.json, move lib files to src folder

[selfiens]

Related to #67

This PR has been made possible thanks to the incorporation of the composer in version 1.5.5 (dfa8fedeca451).

The primary changes in this PR are:

• Updated composer.json to adhere to the official schema.
• Moved dev depencencies to require-dev in composer.json.
• Refreshed composer.lock with the latest dependencies.
• Configured automatic loading of helper.php through composer.json > autoload > files
• Introduced the Perlite namespace and mapped it to the /perlite/src directory.
• Loaded PerliteParseDown and Parsedown using use statement.
  • Removed Parsedown.php from the root and replaced its usage with vendor/erusev/parsedown/Parsedown.php.
• Added blocking rules for /src and /vendor to the Nginx configuration.
• Inserted several global keywords to correspond with the actual global variables in perlite/src/helper.php

I have a few concerns to share:

• Given the existing folder structure, which exposes the /perlite as the web root, mapping the Perlite namespace to /perlite/src might pose issues if someone chooses src as their vault name (as well as vendor). A more unique and restricted folder name, such as .src or .perlite, might be a better choice, though it doesn't align with common practices I'm familiar with. Many popular frameworks set their web root to /public, making it /perlite/public for this project.
• I relocated helper.php to /perlite/src since it's not an intended web entry point, and there's no other suitable location to place it. However, this new location might not be entirely logical in the context of class autoloading.
• helper.php will be loaded automatically for every request. This may not be intended by the original author.

Thanks for taking the time to review. I appreciate your insights and I'm keen to discuss and incorporate any feedback.

[secure-77]

Thanks for the PR, not sure if I can merge it since I have already made some changes in the files in the DEV Branch, I need to add some instruction, that PRs should be done against the DEV Branch to adjust them to the current development status.

One question because it seems you have some experience in this field:

How to manage the JS dependencies? I used php composer but it's a mess, first it downloads too much stuff (I just need some files from the dist folders) and now it also has some conflicts between child dependencies of two dependencies. I don't want or need these child dependencies either, because I won't build the packages. Is there a way to tell composer only to download the wanted files instead of the whole package or is there generally another good approach how to manage this?

My current solution is, that I removed mermaid from composer and load it directly from a CDN because some child dependencies have a conflict with Katex dependencies.

[selfiens]

Thanks for the PR, not sure if I can merge it since I have already made some changes in the files in the DEV Branch, I need to add some instruction, that PRs should be done against the DEV Branch to adjust them to the current development status.

One question because it seems you have some experience in this field:

How to manage the JS dependencies? I used php composer but it's a mess, first it downloads too much stuff (I just need some files from the dist folders) and now it also has some conflicts between child dependencies of two dependencies. I don't want or need these child dependencies either, because I won't build the packages. Is there a way to tell composer only to download the wanted files instead of the whole package or is there generally another good approach how to manage this?

My current solution is, that I removed mermaid from composer and load it directly from a CDN because some child dependencies have a conflict with Katex dependencies.

Oh, that's my bad. I was not aware of the dev branch. I'll close this PR and see what I can do.

I've no experience using composer for anything other than managing PHP packages. I assume other usages might complicate things.

Since this project does not involve JS compiling/bundling, placing static JS library files in a web assets path and loading them with <script> tags seems natural and straightforward. Using CDNs is also straightforward.

[secure-77]

No problem, feel free to create a new on the dev branch and thanks for the info about the JS files, I will think about to include them all via CDNs