Implemented Cally to replace JQuery based daterangepicker

[wes-otf]

Fixes #4475. This removes the existing JQuery-based daterangepicker in favor of implementing the DaisyUI supported Cally. This PR builds off of the theme changes of #4543 and requires that to be merged first.

Also added functionality that will ensure the calendars auto-populate ranges if date filters exist (for both submission all AND table_filter_and_search uses)

Test Steps

• Ensure that the Cally date range picker works as expected in both the submission all view and wherever table_filter_and_search.html is used (like in /projects/reports/)
• Ensure if dates are being filtered, the calendar indicated that upon opening as ranges are pre-populated

[wes-otf]

This is awaiting the merge of #4543 - @frjo do we have any need for JQuery after this? Aside from some rewrites of our own code?

[frjo]

@wes-otf I think you are correct. Only five of our own scripts use jQuery and since we removed select2 I believe only the datepicker remain.

[wes-otf]

@frjo I can open a new issue and do those rewrites so we can toss it once and for all if that sounds good?

[frjo]

@wes-otf Sounds good. The themes PR touch most of these javascripts so best to wait until that is merged.

[wes-otf]

Had a bit of a botched merge but I think this should be ready now - also looks like #4597 got overwritten in some of the rebasing/merging so I added it back here

[frjo]

Works well but is the removal of the fixed option, last 7 days etc., intended? Are they not useful as quick options?

[wes-otf]

@frjo this was baked into the previous daterangepicker library - I can write up an issue to potentially customize this a bit but even chatting with some staff they said it isn't a big deal especially when you can manually customize the range in the query/search bar

[theskumar]

Looks neat! nicely done!

[theskumar]

Question should we try get that in the form -> date(time) input as well?

EDIT: I think given the browser have native support for datepicker, that might be bit overkill and desired should be considered for future.

[frjo]

I created a separate PR for the async downloads on submission all, #4604.

Can we clean upp the commits in this PR a bit? It has become a bit messy.

I think the actual code is good to go after that.

[wes-otf]

Squashed the commits so we should be all good - a bit cleaner now @frjo

[frjo]

@wes-otf Can you take a look at the conflict please. Then we can merge this in.

[wes-otf]

should be good @frjo